CoreWebView2Environment.GetAvailableBrowserVersionString() fails in .744 Package

[RickStrahl]

I'm using CoreWebView2Environment.GetAvailableBrowserVersionString() to check for installed browser runtime versions at runtime. In previous builds this has worked fine but after updating to the latest .NET NuGet package:

PackageReference Include="Microsoft.Web.WebView2" Version="1.0.774.44" />

When I call GetAvailableBrowserVersionString() I get this error:

Unable to load DLL WebView2Loader.dll

Going back to:

PackageReference Include="Microsoft.Web.WebView2" Version="1.0.705.50" />

works.

I've got the the latest, released 89.0.744.63 evergreen runtime installed.

Additional Notes

In my application I try to figure out what runtime is installed if any. If it is I check for the build number and if the build number of the installed runtime is greater than the build number of CoreWebView2 I presume we're good to go (see code in screenshot). Considering that runtimes seem to be forward compatible - is this is a reasonable approach?

In this case the runtime is the same build number (so should pass) but it looks like this is a breaking change in the WebView2 package...

[RickStrahl]

This seems to be a much bigger problem actually... Any versions past 705 seem to have completely broken the WebView2 initialization sequence.

Ignoring the runtime mismatch issues for a moment I installed the latest Dev Canary build and then installed both the 805 and 774 runtimes.

Both of them fail in this initialization code by never returning from the call to await WebBrowser.EnsureCoreWebView2Async(env):

        // ctor called from wrapper (user) control's ctor
        public WebViewPreviewHandler(WebView2 webViewBrowser)
        {
            WebBrowser = webViewBrowser; 

            // externalize so we can use async in the method
            _ = InitializeAsync();
        }

        async Task InitializeAsync()
        {
            // must create a data folder if running out of a secured folder that can't write like Program Files
            var browserFolder = Path.Combine(mmApp.Configuration.CommonFolder, "WebView_Browser");
            var env = await CoreWebView2Environment.CreateAsync(
                userDataFolder: browserFolder
            );

            // 774 and 805 never return from this  - so initialization code never gets fired
            // it works fine in 705 and earlier
            await WebBrowser.EnsureCoreWebView2Async(env);

            WebBrowser.NavigationCompleted += WebBrowser_NavigationCompleted;

            if (Model.Configuration.System.ShowDeveloperToolsOnStartup)
                WebBrowser.CoreWebView2.OpenDevToolsWindow();

            // Set up interop object to pass into JavaScript
            DotnetInterop = new WebViewPreviewDotnetInterop(Model, WebBrowser);
            JsInterop = DotnetInterop.JsInterop;
            WebBrowser.CoreWebView2.AddHostObjectToScript("mm", DotnetInterop);
        }

Any ideas why this is hanging?

[champnic]

Hey @RickStrahl - thanks for the bug report! I'm guessing these all stem from the same "Unable to load DLL webview2loader.dll". Are you running your code in VS when this happens, or deploying it? What is your project type?

If you are trying to build "AnyCPU", can you try building "x64" or "x86"? If that resolves it, then it's likely you need to set a <PlatformTarget>AnyCPU</PlatformTarget> as a default in your csproj file.

Currently if <PlatformTarget> doesn't have a default value, <Platform>AnyCPU<Platform> (the dropdown in the VS solution toolbar) can be interpreted as x86, which will only deploy the x86 version of webview2loader.dll and so will fail to load if the exe is actually compiling x64/AnyCPU and looking for the x64 webview2loader.dll.

[champnic]

We are looking at a general fix for this issue as part of #730 - class library projects are an example where the isn't set by default.

[RickStrahl]

Hmmm... odd behavior.

Tried your suggestion and it's working when explicitly switching to a platform target (x86) in both the class library that hosts the control and the root project (WPF).

Curious that this worked, I then switched back - first the class lib, the the full project back to the AnyCpu and now it works with that too for .774 and also .805.

Then I removed the explicit runtime and left my Dev Canary build in place and that too worked.

Then went back to basically where was (rolled back code, uninstalled Canary, reinstalled .774 runtime) - and the thing still worked.

I have no idea what the heck was going on before, but it was failing reliably with .774 and later runtimes and .774 and later libs. But it seems I'm not the only one seeing this library load error so...

IAC for now closing since I can't repro any more.