WebView2 types exist in both Microsoft.Web.WebView2.Core and Microsoft.WinUI

[edoust]

I have a .NET 5 desktop app with WinUI 3 and these are some of the package references

I am getting this build error:

error CS0433: The type 'CoreWebView2NavigationStartingEventArgs' exists in both 'Microsoft.Web.WebView2.Core, Version=1.0.864.35, Culture=neutral, PublicKeyToken=2a8ab48044d2601e' and 'Microsoft.WinUI, Version=3.0.0.0, Culture=neutral, PublicKeyToken=de31ebe4ad15742b'

The following code is causing the issue, since the type CoreWebView2NavigationStartingEventArgs exists in both Microsoft.WinUI and Microsoft.Web.WebView2.Core:

private void AuthWebView_NavigationStarting(WebView2 sender, Microsoft.Web.WebView2.Core.CoreWebView2NavigationStartingEventArgs args)
{
    var destination = args.Uri;

    if (destination.StartsWith(this.Callback, StringComparison.OrdinalIgnoreCase))
    {
        args.Cancel = true;
        this.Result = new WebAuthenticationResult(destination);
        this.Hide();
    }
}

Will this be fixed in future versions? Is there any workaround for this error?

Explicitly installing the WebView2 package and specifying an alias for it does not work - any input would be appreciated. For now I will continue to use Microsoft.Graph in version 3.*

[llongley]

@Scottj1s Is this C#/WinRT related? I'm curious whether this is a type getting added to the projection that shouldn't be, or whether this is mixing and matching packages that shouldn't go together. Should Microsoft.Graph perhaps go into project that creates a projection binary instead of directly being referenced by a .NET 5 project?

[asklar]

I agree w/Luke, it sounds like this needs a version of the microsoft.graph that uses the projection. I thought the goal was you could mix/match, but maybe things only work if they're using the projection, in which case I worry about what other projects that have indirect dependencies on winrt will need to have a projection created and create more work as the projection requirements "infects" dependencies

[dahovey]

I ran into this as well, referencing the Microsoft.Identity.Client package directly.

[dahovey]

See issue in WebView2 repository:
MicrosoftEdge/WebView2Feedback#1921

[dahovey]

I found a workaround for this! Based on this stackoverflow question here.

1. Add a PackageReference to Microsoft.Web.WebView2. In my case I chose version 1.0.864.35 because other packages I needed to reference, depended on that version.
2. Select the Microsoft.Web.WebView2 package in the Dependencies section of project.
3. Enter an alias, i.e. webivew2

After doing this the Dependencies and Packages nodes within project, show up with a yellow exclamation triangle, but the project builds without error and works.

[jameskilts]

This is also an issue in Maui when adding platform specific browser event handlers, since Maui uses WinUI3+WebView2 on Windows under the hood. While the solution from @dahovey is appropriate, the issue can also be sidestepped by using a lambda expression to define the handler without specifying the type.

private async void WebView_HandlerChanged(object sender, EventArgs e)
{
#if WINDOWS
    if (yourMauiBrowser.Handler?.PlatformView is Microsoft.Maui.Platform.MauiWebView webview)
    {
        await webview.EnsureCoreWebView2Async();
        webview.CoreWebView2.WebResourceRequested += (a,b) => CoreWebView2_WebResourceRequested(a,b);
...

[rossirpaulo]

WindowsApp SDK then is not compatible with Microsoft.Identity?!?! Is there a fix coming along?

[rossirpaulo]

Any ETA?

[baskren]

@dahovey : posted work around does not work (I really, really tried).

Here is a simple demo app showing that the work around does not work: https://github.com/baskren/WinUi3_MSAL_SelfContained_WorkAround_Fail

Here is a simple demo app illustrating the original failure:
https://github.com/baskren/WinUi3_MSAL_SelfContained_Fail

[baskren]

Hi @asklar and @llongley : just reaching out to see if there's anything else I can do to get this issue some more love?

[penndai]

Same error here, we have the WinUI project, and when I add the package Microsoft.Identify.Client, it complains.
The version of Microsoft.WinUI is 3.0.0.0,
The version of Microsoft.Identity.Client is 4.50.0

The type 'CoreWebView2' exists in both 'Microsoft.Web.WebView2.Core, Version=1.0.864.35, Culture=neutral' and 'Microsoft.WinUI, Version=3.0.0.0, Culture=neutral'

[asklar]

I think you can work around it by not creating the WebView2 in markup, but instead creating it in code behind, e.g.

var wv = new WebView2();
grid.Children.Add(wv);
// ...

[MatthewB05]

I'm surprised this has been open for so long without a resolution. It's still an issue as of today - if you try to publish a MAUI app that references Microsoft.Identity.Client, ,you get a conflict between the WebView2 included as standard with WinUI and the one referenced by the MSAL.

I've tried all kinds of techniques from dozens of StackOverflow posts and elsewhere to try and exclude one of the DLLs from the published build, or make MS Build understand that they're the same file so who even cares, but can't get anything to work :

C:\Program Files\dotnet\sdk\7.0.203\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.ConflictResolution.targets(112,5): err
or NETSDK1152: plusieurs fichiers de sortie de publication ayant le même chemin relatif ont été trouvésD:\temp\MauiApp1
\obj\x64\Release\net7.0-windows10.0.19041.0\win10-x64\MsixContent\Microsoft.Web.WebView2.Core.dll, obj\x64\Release\net7
.0-windows10.0.19041.0\win10-x64\R2R\Microsoft.Web.WebView2.Core.dll: . [D:\temp\MauiApp1\MauiApp1.csproj::TargetFramew
ork=net7.0-windows10.0.19041.0]

Edited to add ... the above is only a problem if publishing self-contained. While it might not be possible for everyone, deactivating the self-contained option does at least allow it to work. There may be other people using MAUI who first turned this on because a while back the installer was useless without this option (wasn't capable of actually installing the required dependencies) but that seems to be working at the time of writing.

[Panda-Sharp]

I'm surprised this has been open for so long without a resolution. It's still an issue as of today - if you try to publish a MAUI app that references Microsoft.Identity.Client, ,you get a conflict between the WebView2 included as standard with WinUI and the one referenced by the MSAL.

I've tried all kinds of techniques from dozens of StackOverflow posts and elsewhere to try and exclude one of the DLLs from the published build, or make MS Build understand that they're the same file so who even cares, but can't get anything to work :

C:\Program Files\dotnet\sdk\7.0.203\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.ConflictResolution.targets(112,5): err or NETSDK1152: plusieurs fichiers de sortie de publication ayant le même chemin relatif ont été trouvésD:\temp\MauiApp1 \obj\x64\Release\net7.0-windows10.0.19041.0\win10-x64\MsixContent\Microsoft.Web.WebView2.Core.dll, obj\x64\Release\net7 .0-windows10.0.19041.0\win10-x64\R2R\Microsoft.Web.WebView2.Core.dll: . [D:\temp\MauiApp1\MauiApp1.csproj::TargetFramew ork=net7.0-windows10.0.19041.0]

Edited to add ... the above is only a problem if publishing self-contained. While it might not be possible for everyone, deactivating the self-contained option does at least allow it to work. There may be other people using MAUI who first turned this on because a while back the installer was useless without this option (wasn't capable of actually installing the required dependencies) but that seems to be working at the time of writing.

Sadly I'm not even surprised anymore 😢

[Daniellled]

This issue also exist if you have a WPF application that uses WebView2 and also attempt to use WindowsAppSDK for functionality such as notifications.

The instant you add any code that uses CoreWebView2NavigationStartingEventArgs you receive

CS0433 The type 'CoreWebView2NavigationStartingEventArgs' exists in both 'Microsoft.Web.WebView2.Core, Version=1.0.1823.32, Culture=neutral, PublicKeyToken=2a8ab48044d2601e' and 'Microsoft.WinUI, Version=3.0.0.0, Culture=neutral, PublicKeyToken=de31ebe4ad15742b'

To reproduce I followed these steps https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/wpf-plus-winappsdk#configure-your-wpf-project-for-windows-app-sdk-support followed by these https://learn.microsoft.com/en-us/microsoft-edge/webview2/get-started/wpf (I omitted the .NET Framework stuff since the app is .NET 6)

The instant I add in this code things quit working

void EnsureHttps(object sender, CoreWebView2NavigationStartingEventArgs args)
{
   String uri = args.Uri;
   if (!uri.StartsWith("https://"))
   {
      webView.CoreWebView2.ExecuteScriptAsync($"alert('{uri} is not safe, try an https link')");
      args.Cancel = true;
   }
}

I have uploaded an example that reproduces the issue.

TestAppSDKWebView.zip

[amadeo-alex]

The fact that this issue existed for so long without any traction is at best laughable.
All while UWP Toolkit users are advised to move to the App SDK when encountering a registry bug which was marked as "won't fix because use App SDK"...

[27k1]

When is a fix due for this please? Urgent requirement.

[AMArostegui]

Hi @llongley, as you just marked this as duplicate, can you link to the related issue?

[codendone]

Reopening. The duplicate was an internal issue. I've relinked to that issue.

[WINMAN174]

I can't believe this is still open. Am I missing something?

Found a way around it or at least for WINUI.

Don't use the control directly in XAML. Use a ContentControl in XAML then instantiate the WebView2 control in code and set the ContentControl.Content to the WebView2 control.

Cheers guys. Don't let the AI bite you.

[baskren]

FWIW: The only way I've found to work around this was this approach by @christianfo. @asklar, @codendone, and @llongley: does @christianfo's work around help point to a root cause?

[Ccarmichael92]

I have been using this method for almost 2 years. I figured it out after getting extremely frustrated none of the other methods would work for me for winui3 app. And I am using a webview2 instance as a pdf reader.

Open up obj/project.assets.json and delete any reference to webview2 where it is the key in a key:value pair. For example if webview2. Is referenced within another package you can leave if. But delete all the top level webview2 instances in entire file. Or just delete all instances of it, it will still work. Just ensure you keep the json intact. Then just build and run.

Have to redo this anytime major xaml changes are made. I was going to write a CL all to do automatically but hasn’t been enough of an annoyance yet.

[zadjii]

@Scottj1s Should we x-ref or dedupe this with microsoft/WindowsAppSDK#4249? or some other offshoot of microsoft/WindowsAppSDK#1856 (comment)

[ancker1]

I have been using this method for almost 2 years. I figured it out after getting extremely frustrated none of the other methods would work for me for winui3 app. And I am using a webview2 instance as a pdf reader.

Open up obj/project.assets.json and delete any reference to webview2 where it is the key in a key:value pair. For example if webview2. Is referenced within another package you can leave if. But delete all the top level webview2 instances in entire file. Or just delete all instances of it, it will still work. Just ensure you keep the json intact. Then just build and run.

Have to redo this anytime major xaml changes are made. I was going to write a CL all to do automatically but hasn’t been enough of an annoyance yet.

This is the only working workaround I have encountered.

[ancker1]

I have been using this method for almost 2 years. I figured it out after getting extremely frustrated none of the other methods would work for me for winui3 app. And I am using a webview2 instance as a pdf reader.
Open up obj/project.assets.json and delete any reference to webview2 where it is the key in a key:value pair. For example if webview2. Is referenced within another package you can leave if. But delete all the top level webview2 instances in entire file. Or just delete all instances of it, it will still work. Just ensure you keep the json intact. Then just build and run.
Have to redo this anytime major xaml changes are made. I was going to write a CL all to do automatically but hasn’t been enough of an annoyance yet.

This is the only working workaround I have encountered.

If you are using WebView2 in xaml you will still get an error. See here for a fix: AzureAD/microsoft-authentication-library-for-dotnet#3583 (comment)

[codendone]

This is fixed in 1.6.240701003-experimental2.

[AMArostegui]

I've checked the experimental build, and, at least for me, it does fix the problem

[zpfzhang]

I fixed this issue by install Nuget Microsoft.WindowsAppSDK 1.6.240923002(should work higher than 1.6.240701003-experimental2). hope helpful for others.

[WINMAN174]

Thanks guys!. Check it out. TradingView lightweight charts integrated. Sick.