When using assembly merging, initialising the CoreWebView2Environment throws SystemArgumentException: The path is not of a legal form

[dqwork]

Description
With an executable that references the WebView2 dlls utilizing 'dependency merging' (ie you just distribute a single big file, we are using Smart Assembly for this, but there are other (probably more common) tools), when the CoreWebView2Environment class attempts to find the WebView2Loader.dll it throws an System.ArgumentException: The path is not of a legal form..

Looking at Screenshot 1, it seems that in response to this issue #2277 the code was changed to include both the value from Assembly.Location and Assembly.CodeBase`

However looking into the implementation of GetAssemblyLocationDirectory (screenshot 2), we can start to see where the problem is.

When an Assembly has not been loaded from disk (like when its been merged) Location returns an empty string and Path.GetDirectoryName throws a SystemArgumentException if you pass it an empty string.

Version
SDK: 1.0.1722.45
Runtime: Latest Edge Stable
Framework: Winforms (Merged DLLS in final executable)
OS: Windows 10

Repro Steps

To reproduce this issue the WebView2 Core and Winforms dll's should be 'merged' into the final executable, either that or find some other way for typeof(CoreWebView2Environment).Assembly.Location to return an empty string. Then any simple app that utilises the WebView2Control will throw an exception (System.ArgumentException: The path is not of a legal form.) when it initializes.

ScreenShot 1

Screenshot 2

Additional context
We are using .Net Framework 4.7.2
Again just to reiterate, this issue only happens if the WebView2 dlls (Core, Winforms, WPF) are not loaded from a file location at run time but from some other source. The likely reason for that is when you use assembly merging, but I assume there could be other reasons too.

I would think this would be a relatively quick fix; just add a check that the return value of Assembly.Location is not an empty string before passing it to Path.GetDirectoryName

Thanks

AB#44326158

[novac42]

Thanks for reaching out. I've assigned this to a dev that can follow up on this.

[LiangTheDev]

Created internal tracking work item for the issue. At mean time, you should be able to use CoreWebView2Environment.SetLoaderDllFolderPath to explicitly set loader dll path to workaround the issue.

[dqwork]

The issue with SetLoaderDllFolderPath is that when it is set, all the logic around checking the current processor architecture and getting the path to the right runtime folder becomes 'our' responsibility - which essentially results in copying the code from the WebView2 library and reimplementing it, which isn't ideal to be honest. It results in what should be basic code turning into something more complex requiring PInvoke and various special structs.

So yes you are correct is does provide a work around - its one I'd rather not use and I imagine most people are in the same boat

[sln162]

When we first started embedding, we also encountered this issue. At the time, we didn't use SetLoaderDllFolderPath. Instead, after embedding, we loaded WebView2Loader.dll into memory using LoadLibrary. We also used other tools to embed Microsoft.Web.WebView2.Core.dll and Microsoft.Web.WebView2.WinForms.dll, but encountered the error message "The path to the file is not valid" during embedding.

Later on, we discovered that the tool we used had a "load-from-file" flag that could be used to load the embedded assembly from a file at runtime instead of from memory. This can be used to preserve a meaningful value of the Location property from the System.Reflection.Assembly type.

With this approach, embedding worked correctly for us and the application ran without any issues. Although we are currently using SetLoaderDllFolderPath, both approaches are viable. When we initially encountered this problem, it took me a whole day to troubleshoot and find a solution, and I still remember it vividly now.

[yunate]

@dqwork, I agree with your point of view : using CoreWebView2Environment.SetLoaderDllFolderPath isn't ideal to be honest. And we will increase the search for the path where the DLL runs.

[champnic]

We've checked in a fix for this that should be available to test in the next prerelease SDK (coming out within the next week). Thanks!

[sln162]

The SDK of 1905 did indeed fix this issue, and currently we can merge assemblies without using SetLoaderDllFolderPath