Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Problem/Bug]: How to influence which WebView2Loader.dll is used by WebView2's managed code #4693

Open
awschristou opened this issue Jul 19, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@awschristou
Copy link

What happened?

Hi, we have a Visual Studio 2022 extension that we've recently added the NuGet package Microsoft.Web.WebView2 to. We've recently learned that we have to be careful about what API calls we use, because not every API call is supported by all versions of WebView2.

We are calling a function GetAvailableBrowserVersionString, and GetAvailableBrowserVersionString then calls out to unmanaged code in WebView2Loader.dll. There are two overloads to this function:

GetAvailableBrowserVersionString(string browserExecutableFolder)

This makes a pinvoke call to:

[DllImport("WebView2Loader.dll")]
internal static extern int GetAvailableCoreWebView2BrowserVersionString([In][MarshalAs(UnmanagedType.LPWStr)] string browserExecutableFolder, [MarshalAs(UnmanagedType.LPWStr)] ref string versionInfo);

GetAvailableBrowserVersionString(string browserExecutableFolder, CoreWebView2EnvironmentOptions environmentOptions)

This makes a pinvoke call to:

[DllImport("WebView2Loader.dll")]
internal static extern int GetAvailableCoreWebView2BrowserVersionStringWithOptions([In][MarshalAs(UnmanagedType.LPWStr)] string browserExecutableFolder, ICoreWebView2EnvironmentOptions options, [MarshalAs(UnmanagedType.LPWStr)] ref string versionInfo);

Where things get interesting is that Visual Studio will sometimes have both its own copy of WebView2Loader.dll and our extension's copy of WebView2Loader.dll loaded. Even when we call CoreWebView2Environment.SetLoaderDllFolderPath, there doesn't appear to be a deterministic way to influence which dll is used for the DllImport call when we call GetAvailableBrowserVersionString. When the Visual Studio copy of the dll happens to be used, an "Unable to find an entry point named '?' in DLL 'WebView2Loader.dll'" exception is raised. When our extension's copy of the dll is used, things work as expected.

We're switching to use the overload that supports older versions. Is there something I'm missing that relates to how to control which dll is used for the pinvoke calls? Have you got any other guidance to share (aside from "check the compatibility version of each API call")?

Importance

Important. My app's user experience is significantly compromised.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

126.0.2592.102

SDK Version

1.0.2478.35

Framework

WPF

Operating System

Windows 10, Windows 11

OS Version

No response

Repro steps

  • use Visual Studio in a way that causes it to load its own copy of webview2 dlls first (17.10.4 appears to use 1.0.2151.40)
  • then use my extension in a way that causes it to load its copy of webview dlls second (we're using 1.0.2478.35)
  • try to call the GetAvailableBrowserVersionString() or GetAvailableBrowserVersionString(String, CoreWebView2EnvironmentOptions) overloads from the extension
  • get Unable to find an entry point named '?' in DLL 'WebView2Loader.dll` exception

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

Don't know

Last working version (if regression)

No response

@awschristou awschristou added the bug Something isn't working label Jul 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant