Does the runtime folder contain actual runtimes, or loaders for the runtimes?

[protegesolutions]

I'm kinda confused by this. The compiler emits a folder called runtimes which contains sub-folders for three machine architectures (win-x86, win-x64 and win-arm64) which each contain a native sub-folder within which is are files WebView2Loader.dll.

Now, the doco says that the WebView2 runtimes must be installed on the target machines and that these are usually installed in C:\Program Files (x86)\Microsoft\EdgeWebView\Application and the install state can be checked using registry checks (or an API).

So ... which is true? That the WebView2Loader.dll is an actual runtime and doesn't need to be deployed/distributed if the runtimes are already installed in the EdgeWebView folder? Or that these are not runtimes and are actually loaders for the runtimes?

[Syul968]

Hi @protegesolutions,

The WebView2Loader.dll files are, like their name suggest, loaders for the WebView2 Runtime. They happen to be placed under a directory called "runtimes", but that's just details about the build output. The loader needs to be distributed with your application since it will find the WebView2 Runtime install for your app to use WebView2.

Hope this helps,
Luis

[protegesolutions]

Thanks for your reply. In our case, we are trying to replace the WebBrowser control, due to increasing incompatibilities, in a class library that is consumed by third-party apps, services, web sites, etc. We prefer to keep the library as a single file dll, so we embed references. We can't embed the WebView2Loader.dll files (for two architectures at least) because they are native code. This over-complicates things enormously for us.

Also, the nomenclature of the various code bundles is a bit confusing; we have WebView2Loader contained in a runtimes folder, the WebView2.Core/WinForms/Wpf files referred to as runtimes and the actual EdgeWebView runtimes.

Follow up question: why are the loaders separate from the actual libraries (WebView2.Core/WinForms/Wpf)? Could they not be sequestered within the libraries, thereby obviating the need to distribute them?

I realize that the main problem (for us) is the fact that we are targeting a class library, rather than a desktop app or a service or web app, etc. But I have actually seen references from others asking about class library support. The WebBrowser control gave us a very easy and seamless solution whereas WebView2 ... well, I've spent several days trying to resolve various issues, so far to no avail.

[Syul968]

The WebView2 Loader is a small architecture-specific component that helps apps locate the WebView2 Runtime. Since CLR assemblies can run in a variety of architectures, all WebView2 Loader DLLs are required to ship with your app/component so it works across different devices. The .NET assembly for WebView2 relies on these DLLs shipping with the app/component, in the layout detailed in our documentation: Files to ship with the app.

For clarity, these are the different pieces you're referring to:

• WebView2Loader. A small component that helps apps locate the WebView2 Runtime.
• Microsoft.Web.WebView2.Core. "Core" .NET assembly of the WebView2 API.
• Microsoft.Web.WebView2.WinForms/WPF. WebView2 controls for the WinForms and WPF frameworks.
• WebView2 Runtime. A redistributable runtime that serves as the underlying web platform for WebView2 apps

Have you tried embedding the loader DLLs as resources? Please note that you might also need to extract it during initialization of your component. Also, CoreWebView2Environment.SetLoaderDllFolderPath lets you set the directory to look for the WebView2Loader DLL matching the architecture of the device.