[Feature]: Get user data folder / runtime path without needing an instance of the webview2 control

[ajtruckle]

Describe the feature/enhancement you need

See:

https://stackoverflow.com/q/78225121/2287576

We can get the SDK build number and runtime version without needing an actual browser instance. But we can't do the same for the user data folder and runtime path.

I can compute the UDF myself as I know where ask WV2 to set it. But I'll be relying on WV2 never changing the name of the WV2 folder that it creates. Is that likely to happen?

And surely the WV2 runtime could be exposed without needing an instance?

The scenario/use case where you would use this feature

I want this for my About window where I list system info. In this context I have no browser control active anywhere.

How important is this request to you?

Nice to have. There are other ways to tackle this, but having official API support would be beneficial.

Suggested implementation

No response

What does your app do? Is there a pending deadline for this request?

No response

[victorhuangwq]

@david-risney from what I know, UDF location doesn't really change?
I know that in our Utilities, you can only see UDF with an active webview2 control however.

[ajtruckle]

@victorhuangwq @david-risney
I know that programmatically I could put together:

%localappdata%\company\app\EBWebView

As WV2 appears to use this EBWebView sub folder inside the UDF folder that I state. So as long as EBWebView will never change then I can assume it. But if there was a more robust way ... without needing an active WV2 control.

As for the runtime path, the sample app says it is here:

C:\Program Files (x86)\Microsoft\EdgeWebView\Application\122.0.2365.92

But again, I need the Environment2 to get to this property. Ideally this value could be made more easily available if not the other?

[RickStrahl]

I might be missing something but you can control where the user data folder is going with CreateWebViewEnvironment() and CreateAsync(). You can specify the user data folder and if you don't it's created in the current apps startup path (permissions allowing - or it fails if they don't).

That doesn't help with the runtime folder though which I agree would be useful to have, but you can probably deduce that from the version number.

In a pinch you can find that folder based on the version number though?

[ajtruckle]

@RickStrahl I mention at the outset:

I can compute the UDF myself as I know where I ask WV2 to set it. But I'll be relying on WV2 never changing the name of the [EbWebview sub-folder] that it creates. Is that likely to happen?

Text in brackets has been added for clarity. Now do you see why I would like some support function? Even if I passed it the same UDF path and it return it with the correct sub-folder. Then we are guaranteed it will be correct.

In a pinch you can find that folder based on the version number though?

Technically you are right. But we shouldn’t have to do this. I see no reason for needing an active environment to obtain the installed runtime path for the PC. I understand that some ship their apps with a runtime in their own location, but for me I am always using the OS installed runtime.

[ajtruckle]

Annoyingly, my About window is a property sheet. The second page has a browser control on it. But the third doesn't (where are showing this info). So we still can't get at even that instance because the browser control is not created until the user first selects that page.

[david-risney]

Yes it would not be great to take a dependency on the text EBWebView, although it is very unlikely to change.

Creating the environment object doesn't actually start any webview2 processes until you create a corewebview2 controller from it, so perhaps you can still use the CoreWebView2Environment.UserDataFolder property?

Unfortunately, we don't know the runtime path until a WebView2 is created for a UDF because it may be that there is already a WebView2 running with that UDF against an older version of the runtime and in that case the new WebView2 will attach to the existing webview2 runtime processes.

[ajtruckle]

@david-risney OK, so what is the bare minimum code we need to get this to work?