Make the userData folder location configurable

[jspuij]

The userData folder is currently not specified while creating the environment for Edge on windows:

CoreWebView2Environment.CreateAsync().ConfigureAwait(true);

The userdata folder will be created in the working folder for the process. That might not be a writable directory (e.g. Program Files for an installed application). IT also seems that Rider does not change the working folder during debug, using it's own program files as working folder instead.

We could pass a sensible location somewhere inside (AppData->Local) probably and at least make it configurable.

[jspuij]

Note that there is some precious info in this issue: MicrosoftEdge/WebView2Feedback#297

• The source URL property should not be wet on the Webview before the environment is created (because then it will be created implicitly). This will probably hold true for any method or property that starts initializing the webview.
• We need to come up with a sensible default for the userData folder. However for application level isolation we surely have to consider creating a path that cannot be accessed by another application. A fixed path will certainly share the userData between WebView MBB apps which would be BAD!

[congzhangzh]

@jspuij @Eilon how about allow specific BrowserExecutableFolder, as Edge WebView2 be General Availability and support evengreen Evergreen distribution mode now!

ref:
https://docs.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution#fixed-version-distribution-mode
https://blogs.windows.com/msedgedev/2020/10/19/edge-webview2-general-availability/

[jspuij]

@congzhangzh I don't think we ever want to support the fixed version distribution mode, as this will tie a webview2 application to a specific browser version. The evergreen version will always use the latest webview2 runtime. I don't think distribution of the runtime is part of the scope of MBB, but I'll have @Eilon weigh in on this.

[congzhangzh]

@jspuij I understand the good part of evergreen, but this really limit the scenarios of application deploy. single file deploy is really a great feature of dotnet core, if anypart must tie to os, single file deploy will not be so meaningful.

[Eilon]

I think for now evergreen is the main intended workflow. I am fine if there is some optional support for other modes but I think at this point they are less important and also complicate the testing matrix for Mobile Blazor Bindings.

[congzhangzh]

ok

[Eilon]

Fixed in #246