[Problem/Bug]: Could not load file or assembly 'Microsoft.Web.WebView2.Core' on .Net 9 MAUI

[DharshanBJ]

What happened?

We are experiencing an issue with our packages (produced from this repo: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/main/Directory.Packages.props#L16) that have a dependency on the WebView2 package. When an application using our packages upgrades to .NET 9 MAUI, it crashes with the following exception:

System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Web.WebView2.Core, Version=1.0.2739.15, Culture=neutral'. Could not load file or assembly 'Microsoft.Web.WebView2.Core, Version=1.0.864.35, Culture=neutral, PublicKeyToken=2a8ab48044d2601e'. The system cannot find the file specified.

This issue did not occur with .NET 8 MAUI, but started after upgrading to .NET 9 MAUI. This seems similar to the issue described in WebView2Feedback#4784.

Even after upgrading the WebView2 version to 1.0.2903.40(which should have the fix for #4784), we are still encountering the same issue.

Refere this issue for more details - AzureAD/microsoft-authentication-library-for-dotnet#4933

Importance

Blocking. My app's basic functions are not working due to this issue.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

1.0.2903.40

SDK Version

No response

Framework

WinUI3/WinAppSDK

Operating System

Windows 11

OS Version

No response

Repro steps

This is a simple VS Solution containing a .Net8 and a .Net9 version of the same project. The .Net8 works but the .Net9 does not. https://github.com/user-attachments/files/18798538/MauiMSAL-Test.zip

if you try the .Net9 version you get this error : 'Could not load file or assembly 'Microsoft.Web.WebView2.Core, Version=1.0.864.35, Culture=neutral, PublicKeyToken=2a8ab48044d2601e'. The system cannot find the file specified.'

The csproj files in https://github.com/user-attachments/files/18798538/MauiMSAL-Test.zip have the Maui/.Net/winappsdk versions that causes this issue.

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

No, this never worked

Last working version (if regression)

No response

[Navdeep-ss]

@DharshanBJ
The solution file you shared, I am able to build this for both .net8 and .net9 in visual studio 2022

with the webview2 SDK version 1.0.2792.45

[unrateddi]

Hi @Navdeep-ss , the issue occurs at runtime. Please run the MauiMSAL-9 project and hit the Login button.

[Navdeep-ss]

The Microsoft.Maui.Controls package version 9.0.30 requires Microsoft.Web.WebView2 version 1.0.2792.45 or higher. However, your project is currently using Microsoft.Web.WebView2 version 1.0.864.35. This discrepancy is causing your code to expect a binary for WebView2 version 1.0.864.35, while the available binary version is 1.0.2792.45.

Here is the dependency flow:

graph TD;
    A[Microsoft.Maui.Controls 9.0.30] --> B[Microsoft.Maui.Controls.Core 9.0.30];
    B --> C[Microsoft.Maui.Core 9.0.30];
    C --> D["Microsoft.Web.WebView2 (>= 1.0.2792.45)"];

Loading

You can see the dependency section here

The .NET 9 version has a dependency on WebView2 version 1.0.2792.45 or higher, whereas the .NET 8 version did not have this dependency. You can verify this here

Unfortunately, there is nothing we can do on our end to support your scenario. You will need to update the WebView2 version if you want to use it with MAUI .NET 9.

[mibinoob]

@Navdeep-ss You are plain wrong.
While your statement about package version and requirements are completely correct the issue @unrateddi points out is the core of the problem. I can promise you he has no reference whatsoever to webview version 1.0.864.35 and runs the newest version of webview.

However during runtime, as @unrateddi states, the compiler explicitly asks for webview version 1.0.864.35, and only by downgrading to this version, the webview window to enter login options can be shown.

This, as your dependency flow shows, cannot work on NET9 (among other things), and is the story that brought us here.

Upgrading is simply not an option

EDIT: It is true NET 8 did not have this dependency, however, on NET 8 running newest webview version and sdk 1.6 with MSAL 4.66 likewise gives the same issue, where it compiles but webview window cannot load because webview 1.0.864.35 is required for it to run

[Navdeep-ss]

I see this dependency explicity stated in your Directory.Packages.props.
Are you saying this line is autogenerated?

[mibinoob]

Maybe. Maybe not.
I am asking you to review the image, which shows the core of the issue. Running any other version of webview than 1.0.864.35 simply doesn't work. I highly suggest you read all of AzureAD/microsoft-authentication-library-for-dotnet#4933 for more knowledge

[Navdeep-ss]

@DharshanBJ does even after these AzureAD/microsoft-authentication-library-for-dotnet#5154 changes, you are getting the same error.
In my knowledge the changes in the pr should have fixed the issue?

[Navdeep-ss]

@Navdeep-ss You are plain wrong. While your statement about package version and requirements are completely correct the issue @unrateddi points out is the core of the problem. I can promise you he has no reference whatsoever to webview version 1.0.864.35 and runs the newest version of webview.

However during runtime, as @unrateddi states, the compiler explicitly asks for webview version 1.0.864.35, and only by downgrading to this version, the webview window to enter login options can be shown.

This, as your dependency flow shows, cannot work on NET9 (among other things), and is the story that brought us here.

Upgrading is simply not an option

EDIT: It is true NET 8 did not have this dependency, however, on NET 8 running newest webview version and sdk 1.6 with MSAL 4.66 likewise gives the same issue, where it compiles but webview window cannot load because webview 1.0.864.35 is required for it to run

Just a FYI. The repro solution fails for dot net 8 too with the same error

if you add this line to the csproj file

which specifies that the project should use version 1.0.2739.15. As I mentioned earlier, the issue arises because the library expects version 1.0.864.35, but it is not receiving that version.

For .NET 8, things used to work because there was no directive telling the build to use any version other than 1.0.864.35. However, if we explicitly state in the .csproj to use a different version, it fails.

In the case of .NET 9, MAUI has a dependency on a WebView2 version greater than 1.0.864.35. So, even if you do not explicitly state in your project to NOT use version 1.0.864.35, due to dependency resolution, your solution builds with version 1.0.2792.45. However, at runtime, the library you are using expects version 1.0.864.35, which leads to a runtime file not found error.

[DharshanBJ]

@DharshanBJ does even after these AzureAD/microsoft-authentication-library-for-dotnet#5154 changes, you are getting the same error. In my knowledge the changes in the pr should have fixed the issue?

Hi @Navdeep-ss, we are getting the same error even after upgrading the webview2 version to 1.0.2903.40 here - https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/d0a3fc04980174a61c2ec6434dd28dc626674b92/Directory.Packages.props#L16.

Infact, after making this change, we see this issue on both .Net 8 and .Net 9 MAUI.

[Navdeep-ss]

@DharshanBJ, I’ve identified the reason why we’re still encountering this error even after the version update.

and for now it could be fixed just by adding

 <WebView2EnableCsWinRTProjection>false</WebView2EnableCsWinRTProjection>

in your csproj of the projects which refer your package.

To understand why this is happening we have to go through the nuget package of webview2 mainly these lines of Common.targets

If you see if WebView2EnableCsWinRTProjection is true it will copy Microsoft.Web.Webview2.Core.dll from $(NugetRoot)\runtimes\win-$(EffectivePlatform)\native_uap path to you out bin folder, which is winrt specific dll

But in the repro sample app, this WebView2EnableCsWinRTProjection turns out to be true by default, so it will only execute the first When inside Choose.

Given Microsoft.Identity.Client.Desktop project is targeted for net462 and netcoreapp3.1, it would have required dll from $(NugetRoot)\lib_manual\netcoreapp3.0\Microsoft.Web.WebView2.Core.dll but its getting different dll copied to the project's out bin folder which ends up creating file not found exception at runtime.

The best way to avoid that error for now is just use

<WebView2EnableCsWinRTProjection>false</WebView2EnableCsWinRTProjection>

in the csproj of the app you are using this library with.

This issue occurs because Common.targets was written with the assumption that WebView would be the primary dependency. Some of the logic does not function correctly when WebView is only a transient dependency.

[DharshanBJ]

@Navdeep-ss
Thank you for looking into this. We have a large number of customers facing this issue, and I'm concerned that they might not be aware that they need to add this additional line of code in their projects to work around the problem. Is this information documented anywhere?

Additionally, will there be a proper fix for this issue in the future?

[mibinoob]

Can confirm with both transient and direct references to newest SDK and Webview2, that <WebView2EnableCsWinRTProjection>false</WebView2EnableCsWinRTProjection>
is a working quick fix.

Running WinUI3 .NET8, and MSAL.Desktop.

[panta2705]

I don't find this fix working for .NET 9 and latest MAUI, only a bit different exception occurs when I set <WebView2EnableCsWinRTProjection>false</WebView2EnableCsWinRTProjection>

and without this fix it's as already mentioned

Adding direct reference <PackageVersion Include="Microsoft.Web.WebView2" Version="1.0.2792.45" /> does not change anything either

[unrateddi]

To add, tests should be done both with ms-auth webview but also and a maui webview control in the page. Since the false fixes the ms-auth webview the maui control throws the error @panta2705 mentioned. At least that is the case for us.

[espenrl]

I'm going to fire off some questions having seen through Common.targets in the NuGet package. Random guy taking a look at the issue.

Seems like WebView2EnableCsWinRTProjection should be enabled when using Windows App SDK (which MAUI references). Which implications does that have for Microsoft.Identity.Client.Desktop with regards to MAUI?

Something doesn't seem right about the assembly reference for Microsoft.Web.WebView2.Core.Projection.dll. Is it included twice? Does it resolve correctly for .NET 9? Is the .NET 8 assembly compatible with the .NET 9 SDK?

How should Microsoft.Identity.Client.Desktop and MAUI consume the WebView2 NuGet to maintain compatibility?

• https://github.com/dotnet/maui/blob/main/src/Core/src/Core.csproj
• https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/main/src/client/Microsoft.Identity.Client.Desktop/Microsoft.Identity.Client.Desktop.csproj

[nicop85]

For me setting the flag

<WebView2EnableCsWinRTProjection>false</WebView2EnableCsWinRTProjection>

inside the csproj did the trick. I'm using VS 17.13.3, Net 9 and MAUI 9.0.40. I could open the web login form and login to my app.

It will be nice to know a bit more of the consequences of setting that flag. Do we have to check/find/review for any possible side effects?

[unrateddi]

For me setting the flag

false

inside the csproj did the trick. I'm using VS 17.13.3, Net 9 and MAUI 9.0.40. I could open the web login form and login to my app.

It will be nice to know a bit more of the consequences of setting that flag. Do we have to check/find/review for any possible side effects?

Could you also confirm that you can display a WebView control in a page?

For us setting the flag to false does the trick only for the authentication webview. But there is another error when trying to display a MAUI WebView control in the pages. In the same manner we could just reference the old WebView version and authentication would work like a charm, no flag needed. But both approaches break the framework WebView control.

[panta2705]

Exactly, we are using MAUI Hybrid and having <BlazorWebView> control is what is causing the issues for us when setting the flag to false. There are even build errors on lines like bellow in case of setting the flag to false

[nicop85]

Could you also confirm that you can display a WebView control in a page?

For us setting the flag to false does the trick only for the authentication webview. But there is another error when trying to display a MAUI WebView control in the pages. In the same manner we could just reference the old WebView version and authentication would work like a charm, no flag needed. But both approaches break the framework WebView control.

@unrateddi In my case I only use the WebView for the authentication.

[Lakshmisha-KS]

The solution provided by @Navdeep-ss partially mitigates for some of the scenarios where there is a transient reference. The full solution across all scenarios of transient reference is a feature requirement. Hence, I am marking the same and will be part of backlog. We will prioritize this basis the need for this.

[DevDachi]

Unfortunately, workaround provided by Navdeep-ss does not work for our scenario.

This workaround fixes MSAL.Net issue, but further down the line our codebase is using WebView control to display html/pdf content and it throws following error after adding workaround by Navdeep-ss.

Could not load file or assembly 'Microsoft.Web.WebView2.Core.Projection, Version=1.0.2903.40,

Issue is repro in Windows ARM.

Ref: dotnet/maui#26003

Edit: Issue is repro both Windows ARM and x64.

@Lakshmisha-KS / @Navdeep-ss kindly bring this issue back on top of list as we are blocked to migrate to Dotnet 9.

[espenrl]

Microsoft.Maui.dll has a hard reference on Microsoft.Web.WebView2.Core.Projection.dll

See https://github.com/dotnet/maui/blob/7e7ae0815716c0c6ce040aaa8ea3e7b0da6b148d/src/Core/src/Platform/Windows/MauiWebView.cs#L104

[unrateddi]

@Navdeep-ss Any updates on this? We are unable to use both MSAL.Net WebView and MAUI WebView control in our MAUI apps.

[richardschoen]

FWIW - I just had the same rendering issue on latest version of Visual Studio. I updated my MAUI components to 9.0.50 and it seems to work OK on ARM64. Although I did have to target ARM64 on the build.

I suppose that would be an issue since I need to target X86 as well as ARM.

[unrateddi]

@richardschoen did you manage to use MSAL.Net and a MAUI WebView control in some page and both worked as expected? If yes could you provide a sample project because I am unable to make work not matter what I try. I don't think architecture has anything to do with it as the issue is related to package references and different architecture target shouldn't change the behavior.

[richardschoen]

Here's what I did:

Latest install on VS 2022 updates. Version: 17.13.5

ARM Galaxybook4

-Create new .Net Maui Blazor Hybrid app.
-Update Maui Controls to 9.50.

-Make platform target ARM64 instead of Any CPU.

App runs and renders correctly as ARM64, but not with Any CPU

Good for development on ARM64 but probably not for final build.

Windows 11 for ARM on with Parallels on Mac

-Create new .Net Maui Blazor Hybrid app.
-Update Maui Controls to 9.50.
-Make platform target ARM64 or Any CPU and works in both cases.

Not sure why Parallels works for Any CPU once the controls are updated since MacOS is still a variation of ARM64 and both systems are running Windows 11 for ARM.

Although I just set it to x64 and I did get the architecture incompatability issue so pretty much the same issue as the Galaxy.

I wonder is there's a way to install the Non-Arm version of VS 2022 on Windows 11 ARM ?

[unrateddi]

@richardschoen are you using Microsoft.Identity.Client.Desktop package? I don't see it in your packages. If not then your issue is probably not related to this topic.

[ivanjx]

not sure if this is related but i got similar errors with BlazorWebView on WinForms (msix packaged).

System.IO.FileNotFoundException: 'Could not load file or assembly 'Microsoft.Web.WebView2.WinForms, Version=1.0.2903.40, Culture=neutral, PublicKeyToken=2a8ab48044d2601e'. The system cannot find the file specified.'

<Project Sdk="Microsoft.NET.Sdk.Razor">

  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net9.0-windows10.0.26100.0</TargetFramework>
    <Nullable>enable</Nullable>
    <UseWindowsForms>true</UseWindowsForms>
    <SupportedOSPlatformVersion>10.0.19041.0</SupportedOSPlatformVersion>
    <RuntimeIdentifiers>win-x86;win-x64;win-arm64</RuntimeIdentifiers>
  </PropertyGroup>

  <ItemGroup>
    <Content Remove="Properties\appSettings.json" />
  </ItemGroup>

  <ItemGroup>
    <EmbeddedResource Include="Properties\appSettings.json" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Components.WebView.WindowsForms" Version="9.0.50" />
    <PackageReference Include="Microsoft.Extensions.Configuration.Json" Version="9.0.3" />
    <PackageReference Include="Microsoft.Extensions.Configuration.UserSecrets" Version="9.0.3" />
    <PackageReference Include="Microsoft.Extensions.Hosting" Version="9.0.3" />
    <PackageReference Include="Microsoft.WindowsAppSDK" Version="1.7.250310001" />
    <PackageReference Include="SharpHook" Version="5.3.8" />
  </ItemGroup>

</Project>

[Lakshmisha-KS]

Thanks for your patience while we investigated this issue.

After further analysis, we've identified that the root cause stems from a compatibility conflict between the Microsoft Authentication Library (MSAL.NET) and WebView2 in .NET 9 MAUI applications. Specifically, the issue arises because the Windows Authentication package depends on the non-WinRT version of core.dll from WebView2, whereas the application itself is using the WinRT-based version.

WebView2 is not architected to support interoperability between the WinRT and non-WinRT variants of core.dll, which leads to the observed behavior.

A potential resolution would involve updating the Windows Authentication package to support the WinRT-based core.dll version of WebView2, thereby aligning both components to use the same runtime. However, implementing such a change would fall under the purview of the Windows Authentication team.

At this point, there are no further changes we can make on our end to resolve this conflict. For those affected, we recommend reaching out to the Windows Authentication team to explore possible support for the WinRT-based WebView2 runtime.