Crash on .NET Framework 4.7.2

[OgreTransporter]

Description
According to the page https://docs.microsoft.com/en-us/microsoft-edge/webview2/ WebView2 should run from .NET Framework 4.5. However, the example (https://github.com/MicrosoftEdge/WebView2Samples/tree/master/GettingStartedGuides/WPF_GettingStarted) does not work with the current version of WebView2 on net472. The last version it works with is 1.0.705.50.

System.BadImageFormatException
  HResult=0x8007000B
  Message=Es wurde versucht, eine Datei mit einem falschen Format zu laden. (Ausnahme von HRESULT: 0x8007000B)
  Source=Microsoft.Web.WebView2.Core
  StackTrace:
   at Microsoft.Web.WebView2.Core.CoreWebView2Environment.CreateCoreWebView2EnvironmentWithOptions(String browserExecutableFolder, String userDataFolder, ICoreWebView2EnvironmentOptions options, ICoreWebView2CreateCoreWebView2EnvironmentCompletedHandler environment_created_handler)
   at Microsoft.Web.WebView2.Core.CoreWebView2Environment.<CreateAsync>d__3.MoveNext()
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Web.WebView2.Wpf.WebView2.<>c__DisplayClass26_0.<<EnsureCoreWebView2Async>g__Init|0>d.MoveNext()
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
   at WPFSample.MainWindow.<InitializeAsync>d__1.MoveNext() in D:\WebView2Samples-master\GettingStartedGuides\WPF_GettingStarted\MainWindow.xaml.cs:line 35

Version
SDK: 1.0.864.35
Runtime: 91.0.864.48
Framework: WPF (net472)
OS: Win10

Repro Steps

1. Download sample app from https://github.com/MicrosoftEdge/WebView2Samples/tree/master/GettingStartedGuides/WPF_GettingStarted
2. Set TargetFramework to net472
3. Update PackageReference to current version (1.0.864.35)

AB#36226098

[AndyT-MS]

I think that I've discovered the concrete circumstances which cause this bug: it occurs when you use an SDK-style csproj to target net472 (or probably any other version of .NET Framework). Using an SDK-style csproj to target netcoreapp* (i.e. .NET Core) works fine, and using an old-style csproj to target net* (i.e. .NET Framework) works fine.

To summarize, using WebView2 in:

• an old-style csproj targeting .NET Core (netcoreapp): I'm pretty sure that .NET doesn't support this
• an old-style csproj targeting .NET Framework (net): works fine
• an SDK-style csproj targeting .NET Core (netcoreapp): works fine (w/ minor caveat described in my last paragraph)
• an SDK-style csproj targeting .NET Framework (net): this bug occurs

Once you're in the specific case that causes this bug, the way that it manifests actually depends on a few more factors: the PlatformTarget specified in your app, and whether your app depends on WebView2 directly or indirectly.

If your app depends directly on the WebView2 SDK NuGet package, then here are the possible outcomes based on the PlatformTarget property in your app's csproj. Assume that OUTPUT is your app's build output folder.

• PlatformTarget not specified: WebView2 creates both OUTPUT/WebView2Loader.dll (x86) and OUTPUT/runtimes/win-x86/*. If you try to run the app on an x64 machine then you get the BadImageFormatException mentioned in the original post because the only available loader DLLs are x86. This is a bug. The desired behavior for this case is the same as explicitly setting PlatformTarget to AnyCPU. The symptoms of this bug generally match Using WebView2 in a WPF Assembly #730 but unfortunately my fix for that bug isn't fixing this case where an SDK-style project is being used. Workaround: explicitly set <PlatformTarget>AnyCPU</PlatformTarget> in your csproj.
• PlatformTarget set to AnyCPU: WebView2 creates OUTPUT/runtimes/win-arm64/*, OUTPUT/runtimes/win-x64/*, and OUTPUT/runtimes/win-x86/*. A loader is available for all supported architectures, so everything works.
• PlatformTarget set to x64: WebView2 creates both OUTPUT/WebView2Loader.dll (x64) and OUTPUT/runtimes/win-x64/*. Everything works as expected as long as you only run the app on the targeted x64 architecture. It's still probably a bug that WebView2 creates two copies of the DLL.
• PlatformTarget set to x86: WebView2 creates both OUTPUT/WebView2Loader.dll (x86) and OUTPUT/runtimes/win-x86/*. Everything works as expected as long as you only run the app on the targeted x86 architecture. It's still probably a bug that WebView2 creates two copies of the DLL.
• PlatformTarget set to Arm64: I didn't test this, but suspect that it will match the above x64 and x86 cases.

If your app depends indirectly on WebView2 (i.e. your app depends on some other NuGet package which in turn depends on WebView2), then here are the possible outcomes based on the PlatformTarget property in your app's csproj:

• PlatformTarget not specified: WebView2 creates OUTPUT/WebView2Loader.dll (x86). If you try to run the app on an x64 machine then you get the BadImageFormatException mentioned in the original post because the only available loader DLL is x86. This is a bug. The desired behavior for this case is the same as the desired behavior for explicitly setting PlatformTarget to AnyCPU. The symptoms of this bug generally match Using WebView2 in a WPF Assembly #730 but unfortunately my fix for that bug isn't fixing this case where an SDK-style project is being used.
• PlatformTarget set to AnyCPU: WebView2 doesn't create any loader DLLs in the output. When you run the app you get a DllNotFoundException. This is a bug. The desired behavior is that WebView2 create all supported OUTPUT/runtimes/* folders so that an appropriate loader DLL is available for all supported architectures.
• PlatformTarget set to x64: WebView2 creates OUTPUT/WebView2Loader.dll (x64). Everything works as expected as long as you only run the app on the targeted x64 architecture. It's still probably a bug that WebView2 creates that DLL instead of creating OUTPUT/runtimes/win-x64/*.
• PlatformTarget set to x86: WebView2 creates OUTPUT/WebView2Loader.dll (x86). Everything works as expected as long as you only run the app on the targeted x86 architecture. It's still probably a bug that WebView2 creates that DLL instead of creating OUTPUT/runtimes/win-x86/*.
• PlatformTarget set to Arm64: I didn't test this, but suspect that it will match the above x64 and x86 cases.

Basically the difference between your app depending on WebView2 directly vs indirectly is that in the direct case WebView2 creates various OUTPUT/runtimes/* folders and in the indirect case it does not. I believe that the desired behavior in all cases would be to create the relevant OUTPUT/runtimes/* folders and to NOT create OUTPUT/WebView2Loader.dll, but I'm not certain of that yet.

If you're in the case of indirectly depending on WebView2 then I don't yet have any appealing workarounds to suggest. Unappealing possibilities include switching to an old-style csproj for targeting .NET Framework or hacking together some post-build logic to grab the correct DLL or runtime folder(s) out of the WebView2 NuGet package.

Lastly, one more unexpected thing that I discovered while investigating this, and could end up being fixed at the same time, is that in the case of an SDK-style csproj targeting netcoreapp, WebView2 always creates all supported OUTPUT/runtimes/* folders even if your app's PlatformTarget is only set to a specific one. For example, if your app sets PlatformTarget to x64, then WebView2 will still create OUTPUT/runtimes/win-x86 and OUTPUT/runtimes/win-arm64 even though they're unnecessary. This doesn't break anything, which is why I described it as working fine at the top of this comment, but in platform-specific builds it would result in a few small, extraneous files hanging around and potentially getting deployed with your app.

[czdietrich]

I would like to add (in case this is not known) that the property that usually determines what (native) DLLs are copied to the output for SDK style projects is the RuntimeIdentifier property.

• For .NET Framework the RuntimeIdentifier is derived from the PlatformTarget, see here.
• For .NET Core you either do not specify the RuntimeIdentifier and the whole runtimes folder structure is created in the output folder. (So the output is kind of portable)
• Or for .NET Core if you specify a RuntimeIdentifier (usually in combination with dotnet publish), then only the (native) DLLs for that specific runtime are copied to the output folder without any runtimes folder structure.

This all happens by default for SDK style projects, so there should be no need for manually copying DLLs to the output folder as it is currently done in the Common.targets file of the WebView2 NuGet.
So, it might be enough to just check for the UsingMicrosoftNETSdk property to determine, whether the current project is an SDK style project, and in that case do not any manual copying.