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: https://github.com/MicrosoftEdge/WebView2Feedback/issues/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.

[esmondmissen]

So I've tried all the work arounds and still can't publish an application. Any word from Microsoft or is MAUI abandoned already?

[MikeG96]

Any update of this?

[IQTechSolutions]

Maui is a flop. they do not support it. Bugs dont get fixed. microsoft does not even step in in any forum. This is rediculous, I am truly about to give up on maui.

[27k1]

Bad language helps no-one. But we need a solution to this, is there anyone there to respond.

[Dev-Taehui]

I'm very sorry to you all, but I'm not sorry to MS at all.

When I think about the stress I've been under due to MS's slowdown strike, I feel like my lifespan has been cut in half.

[27k1]

Yes, there dev teams need to get sorted out. Or, perhaps, routed out 😉

Peter Farrer Co-Founder 27k1 Ltd

Mob: +44 (0) 794 678 4302

Peter is a Certified IBITGQ ISO27001:2013 Lead Auditor and Lead Implementer

https//27k1.com<https/27k1.com>

From: Dev Taehui @.> Sent: Thursday, October 12, 2023 10:04 AM To: microsoft/microsoft-ui-xaml @.> Cc: Peter Farrer @.>; Comment @.> Subject: Re: [microsoft/microsoft-ui-xaml] WebView2 types exist in both Microsoft.Web.WebView2.Core and Microsoft.WinUI (#5689)

I'm very sorry to you all, but I'm not sorry to MS at all.

When I think about the stress I've been under due to MS's slowdown strike, I feel like my lifespan has been cut in half.

— Reply to this email directly, view it on GitHubhttps://github.com/microsoft/microsoft-ui-xaml/issues/5689#issuecomment-1759218841, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATNSI4TWROL4W5RLOIUNJPTX66W7XANCNFSM5CE73QMQ. You are receiving this because you commented.Message ID: @.@.>>

This e-mail and any files transmitted with it may contain confidential information, intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender of this email. 27k1 Ltd is a company registered in England and Wales. Registered number: 11267122. Registered office: 22 Market Place, Kendal, LA9 4TN, United Kingdom

[baskren]

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);
// ...

@asklar : I am just seeing your response to my question about a work around. Please note that, I am not directly using WebView2. Rather, I'm using MSAL (Microsoft Identity Library). The MSAL team has multiple times pointed me (and others) to this team as the root cause of this issue:

• https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/3941
• https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/3583

In fact, they state that your team is aware of this: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/3583#issuecomment-1424467868

Please note, my intent isn't to throw anyone under the bus. Like everyone else here, we've been unable to ship product for over a year and a half because of this issue. Resolution of the issue would be very welcome.

[DonaldAirey]

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);
// ...

I don't know why this was voted down, but it worked for me. The problem, as nearly as I can tell, is with the XAML. It scours the default namespaces for a control called WebView2, and when it finds it in both Microsoft.Identity and Microsoft.WindowsAppSDK packages, it complains.

[Denreik]

I got this issue with Uno.WinUI (v.5.0.48) and Microsoft.UI.Xaml on Win10. Gets resolved after I downgrade Microsoft.UI.Xaml to version 2.7.3. or below.

[AMArostegui]

I got hit by this issue too, I don't know exactly when because I've already been using a WebView2, and publishing a self-contained app for a while.

Since, I've downgraded to a WinAppSdk and Build Tools version I know were previously working (thanks Git), with no luck. To pinpoint the error by removing code step by step is too much work, and I think it might have to do with a WebView2 system update. It's hard to know.

The thing is, just to compile my project, both solutions proposed here worked. I can either install Microsoft.Web.WebView2 NuGet package, or create the WebView2 at runtime, using lambda expressions for event handlers.

But publishing never seemed to work. I got the Nuget Microsoft.Web.WebView2.Core.dll assembly clashing with MsixContent\Microsoft.Web.WebView2.Core.dll. The latter assembly must be a Microsoft.Ui.Xaml.Controls dependency, I don't know about the former... maybe some transitive dependency?

In the end this Stackoverflow question saved the day. I just needed to add ErrorOnDuplicatePublishOutputFiles to my csproj file to ignore duplicate files. I assume the last file wins, so this might be a concern for versioning.

By the way, I see this issue as big enough to get a little care by the WinUi / WebView teams. I know resources are limited, but Microsoft's triage needs to improve

[leinad13]

I've been hit by this bug trying to build a WinUI3 app and use the Azure.Identity package (which uses Microsoft.Identity.Client). The workaround using ErrorOnDuplicatePublishOutputFiles set to false, doesnt work for me - and neither does adding the WebView2 package with an alias.

Has anyone found any other workarounds?

I guess we are stuck either using workarounds, or just not using Winui3 / MAUI at all as Microsoft aren't going to fix this critical bug - its over 2 years old now...

[DRAirey1]

Has anyone found any other workarounds?

Yes. Don't attempt to use XAML to create the control. The algorithm for finding the library where the control lives has a bug in it and uses the wrong package. You can reference the control just fine in the code-behind. The solution I posted above works just fine. I have this control in a production product and it's reliable.

I agree about how outrageous it is that this particular bug hasn't been addressed in two years, though.

[leinad13]

@DRAirey1 thanks for trying to help, unfortunately I'm not using a WebView2 control anywhere in my XAML. I get an error during build relating to two output files with the same relative path. As far as I can tell from the various issues logged here and in the other repositories relating to this, its because the Windows SDK has a WebView2 control built into the SDK instead of using a nuget package. In my case, I'm trying to use the nugest package Azure.Identity which depends on Microsoft.Identity.Client which depends on Microsoft.Web.WebView2

When the app trys to build it raises NETSDK1152 .

I have tried adding the build parameter ErrorOnDuplicatePublishOutputFiles set to false, to my project but it doesn't seem to do anything.

I also tried adding Microsoft.Web.WebView2 as a nuget package and setting an alias, but this didnt work for me either.

Severity Code Description Project File Line Suppression State Error NETSDK1152 Found multiple publish output files with the same relative path: source\repos\AzureToolkit\AzureToolkit\obj\x64\Debug\net7.0-windows10.0.19041.0\MsixContent\Microsoft.Web.WebView2.Core.dll, .nuget\packages\microsoft.web.webview2\1.0.864.35\lib\netcoreapp3.0\Microsoft.Web.WebView2.Core.dll. AzureToolkit C:\Program Files\dotnet\sdk\8.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.ConflictResolution.targets 112

Edit - I've noticed it is listed as a Known issue since v1.1 in the Windows SDK - but still no resolution.