`Uno.WinUI.MSAL` and `WindowsAppSDKSelfContained` clash

[MartinZikmund]

Current behavior

After adding Uno.WinUI.MSAL and setting <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained> in Windows .csproj, build fails with:

C:\Program Files\dotnet\sdk\8.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.ConflictResolution.targets(112,5): error NETSDK1152: Found multiple publish output files with the same relative path: C:\Dev\mzikmund\src\app\MZikmund.Windows\obj\x64\Debug\net8.0-windows10.0.19041.0\MsixContent\Microsoft.Web.WebView2.Core.dll, C:\Users\marti.nuget\packages\microsoft.web.webview2\1.0.864.35\lib\netcoreapp3.0\Microsoft.Web.WebView2.Core.dll.

Expected behavior

Should not fail build

How to reproduce it (as minimally and precisely as possible)

No response

Workaround

No response

Works on UWP/WinUI

None

Environment

No response

NuGet package version(s)

No response

Affected platforms

Windows

IDE

No response

IDE version

No response

Relevant plugins

No response

Anything else we need to know?

No response

[jeromelaban]

Feels similar to https://github.com/microsoft/microsoft-ui-xaml/issues/8857

[christianfo]

I ran into the same problem. All it takes is to add a dependency on Microsoft.Identity.Client (Version 4.58.1) to the "shared" app project of an Uno sample app (from the Visual Studio templates). Then try to build and you get:

C:\Program Files\dotnet\sdk\8.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.ConflictResolution.targets(112,5): error NETSDK1152: Found multiple publish output files with the same relative path: 
C:\uno\UnoApp13\UnoApp13\UnoApp13.Windows\obj\x86\Debug\net7.0-windows10.0.19041.0\win-x86\MsixContent\Microsoft.Web.WebView2.Core.dll, 
C:\Users\[username]\.nuget\packages\microsoft.web.webview2\1.0.864.35\lib\netcoreapp3.0\Microsoft.Web.WebView2.Core.dll.

Adding a reference to package Microsoft.Web.WebView2 (instead of Microsoft.Identity.Client) creates the same issue. Microsoft.Identity.Client depends on Microsoft.Web.WebView2 and brings it in. Microsoft.Web.WebView2 is the package that causes the "multiple publish output file" issue, apparently conflicting with a Microsoft.WebView2.Core.dll brought in by the MSIX packaging.

Adding a reference to package Uno.WinUI.MSAL also causes the same issue, as it depends on Microsoft.Identity.Client.

Adding a reference to either of these packages in a WinUI3 app works fine.

Note that this problem only affects the Windows build, not WASM or Android.

So far, I have not been able to make the workaround mentioned in 8857 work.

[christianfo]

Tried upgrading Uno packages from 5.0.118 to 5.1.0-dev.1108. That did not help.

[christianfo]

@jeromelaban, any pointer as to how to try to make a workaround?

[baskren]

@christianfo : Just a guess at a potential work around (at the moment I don't have the time to try this out) :

What about adding ExcludeAssets="all" to the <PackageReference Include="Uno.UI.MSAL" />, and then including <PackageReference Include="Uno.UI.MSAL" /> in the platform (Windows) project?

UPDATE : No, didn't work. Nor did going into the ~/.nuget/packages/microsoft.identity.client/4.58.1/microsoft.identity.client.nuspec and making the following edits:

      <group targetFramework="net6.0-windows7.0">
        <dependency id="Microsoft.Identity.Client.NativeInterop" version="0.13.14" exclude="Build,Analyzers" />
        <dependency id="Microsoft.IdentityModel.Abstractions" version="6.22.0" exclude="Build,Analyzers" />
        <!--<dependency id="Microsoft.Web.WebView2" version="1.0.864.35" exclude="Build,Analyzers" />-->
        <dependency id="System.Diagnostics.DiagnosticSource" version="7.0.2" exclude="Build,Analyzers" />
      </group>

... which I really hoped would work!

[christianfo]

Thank you very much, @baskren! With your proposed workaround, I get compilation errors everywhere I am referring to anything in Microsoft.Identity.Client or Uno.WinUI.MSAL (that code is in a "shared" project). I am toying with excluding only some of the assets, not all, but so far, no luck.

[christianfo]

@christianfo : Just a guess at a potential work around (at the moment I don't have the time to try this out) :

What about adding ExcludeAssets="all" to the <PackageReference Include="Uno.UI.MSAL" />, and then including <PackageReference Include="Uno.UI.MSAL" /> in the platform (Windows) project?

UPDATE : No, didn't work. Nor did going into the ~/.nuget/packages/microsoft.identity.client/4.58.1/microsoft.identity.client.nuspec and making the following edits:

      <group targetFramework="net6.0-windows7.0">
        <dependency id="Microsoft.Identity.Client.NativeInterop" version="0.13.14" exclude="Build,Analyzers" />
        <dependency id="Microsoft.IdentityModel.Abstractions" version="6.22.0" exclude="Build,Analyzers" />
        <!--<dependency id="Microsoft.Web.WebView2" version="1.0.864.35" exclude="Build,Analyzers" />-->
        <dependency id="System.Diagnostics.DiagnosticSource" version="7.0.2" exclude="Build,Analyzers" />
      </group>

... which I really hoped would work!

Thanks for trying this out! I tried something similar by excluding the same in the PackageReference of WebView2, but that did not work either. Note that I have an app that needs Uno.WinUI.MSAL, but another one where I need WebView2 as well. I have been trying to build a patch similar to what is in 8857, but to no avail so far.

[baskren]

MsalTest2.zip

@christianfo : Starting to see if I can get this work, I started with a new WinUI3 app template and flushed out MSAL support, Microsoft.Datasync.Client support, and then changes to the Window's platform project's .csproj to support net7.0 Release builds and net8.0. The result is attached, above. I'm going to repeat this process with a new Uno.WinUI template and see what's different.

[christianfo]

@baskren, thanks for doing these experiments! I have had the same experience. I have been able to make MSAL auth work via Microsoft.Identity.Client and also WebView2 using Microsoft.Web.WebView2 on new and existing WinUI3 projects. On Uno, I tried to add MSAL auth on an existing Uno app and a new app created from the VS templates. Both yielded the same "Found multiple publish output files with the same relative path" error.

[christianfo]

I have been trying to find the place in the build process (in particular the MSIX part of it) where I could prune out the duplicated WebView2 files that it is complaining about in a manner similar to the work around shown in 8857 but so far, I have not been successful.

[christianfo]

In case that is useful, here are the WinUI3 and Uno sample apps I was trying MSAL on. In each app, OneDrive.cs has very simple code to authenticate to OneDrive with an MSA. I have X'ed out the client id for security reasons. Replace by yours if you want to try this. Your app registration should support Microsoft Personal Account and use the default URL (first suggested).

WinUI3 app: App1.zip

Uno app (does not build for Windows, but builds for WASM and Android): UnoApp13.zip

[baskren]

@christianfo -

OK, I believe that I've figured it out. Here is what I learned:

1. Adding aUno.WinUI.MSAL or Microsoft.Identity.Client nuget package to an Uno Platform app project works out of the box, using the most recent templates.
2. Immediately after adding a Uno.WinUI.MSAL or Microsoft.Identity.Client nuget package to an Uno Library (using the most recent templates) VisualStudio 2022 (or dotnet restore) gives the following errors during the restore:

error NETSDK1082: There was no runtime pack for Microsoft.WindowsDesktop.App.WindowsForms available for the specified RuntimeIdentifier 'win10-arm'
error NETSDK1082: There was no runtime pack for Microsoft.WindowsDesktop.App.WindowsForms available for the specified RuntimeIdentifier 'win10-arm-aot'

3. Since, in the Uno App, the cross-platform application project is (for all practical purposes) just a cross-platform library, what are the differences? Taking a closer look, I decided to add the following lines into the <When Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'windows'"> block of the Uno Library project that used an MSAL nuget:

      <PropertyGroup>
        <!-- The following eliminated " error NETSDK1082: There was no runtime pack for Microsoft.WindowsDesktop.App.WindowsForms available for the specified RuntimeIdentifier 'win10-arm' / 'win10-arm-aot'." -->
        <RuntimeIdentifiers>win10-x86;win10-x64;win10-arm64</RuntimeIdentifiers>
        <UseRidGraph>true</UseRidGraph>
        <UseWinUI>true</UseWinUI>
      </PropertyGroup>

With those additional lines, the dotnet restore worked from the command line and VisualStudio 2022 was happy when loading the Uno Library project. Next, I was able to successfully build the Uno Library. Finally, I returned to my POC project, applied all of these changes, and was able to successfully build Debug/Release builds and successfully Package and Publish for x86, x64 and arm64!

UnoMsalApp2.zip

[christianfo]

@baskren, thank you! When I try to build the UnoMsalApp2 that you posted above, I still get the following error:

9>C:\Program Files\dotnet\sdk\8.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.ConflictResolution.targets(112,5): error NETSDK1152: Found multiple publish output files with the same relative path: 
C:\uno\UnoMsalApp2\UnoMsalApp2\UnoMsalApp2.Windows\obj\x64\Debug\net8.0-windows10.0.19041.0\win-x64\MsixContent\Microsoft.Web.WebView2.Core.dll, 
C:\Users\chris.CHRISF103\.nuget\packages\microsoft.web.webview2\1.0.864.35\lib\netcoreapp3.0\Microsoft.Web.WebView2.Core.dll.

Since you are able to build on your machine, there must be something specific to my environment that is different. Maybe it has to do with the version(s) of WebView2 NuGet packages present on my machine. I will dig a bit further in that direction.

[baskren]

Both hypotheses sound mildly plausible.

Just out of curiosity, what happens when you start with a fresh dotnet new unoapp -o UnoMsalTest, add the following to the .csproj, and then try to build/run?

<ItemGroup>
    <PackageReference Include="Microsoft.Indentity.Client" Version="4.58.1" />
</ItemGroup>

Perhaps it is my environment (M2 MBP + Windows 11 ARM via Parallels). FWIW:

Visual Studio 2022 Info

Microsoft Visual Studio Community 2022 Version 17.8.3 VisualStudio.17.Release/17.8.3+34330.188 Microsoft .NET Framework Version 4.8.09032

Installed Version: Community

Visual C++ 2022 00482-90000-00000-AA155 Microsoft Visual C++ 2022

ASP.NET and Web Tools 17.8.358.6298 ASP.NET and Web Tools

Azure App Service Tools v3.0.0 17.8.358.6298 Azure App Service Tools v3.0.0

Azure Functions and Web Jobs Tools 17.8.358.6298 Azure Functions and Web Jobs Tools

C# Tools 4.8.0-7.23572.1+7b75981cf3bd520b86ec4ed00ec156c8bc48e4eb C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

CleanBinAndObjCommand Extension 1.2.58 CleanBinAndObjCommand Visual Studio Extension Detailed Info

Extensibility Message Bus 1.4.39 (main@e8108eb) Provides common messaging-based MEF services for loosely coupled Visual Studio extension components communication and integration.

Microsoft JVM Debugger 1.0 Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines

NuGet Package Manager 6.8.0 NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/

Project System Tools 1.0 Tools for working with C#, VisualBasic, and F# projects.

Razor (ASP.NET Core) 17.8.3.2358002+8c7fb27bf8e8d4f9ff8080b624b35bca5e812e97 Provides languages services for ASP.NET Core Razor.

SQL Server Data Tools 17.8.119.0 Microsoft SQL Server Data Tools

TypeScript Tools 17.0.20920.2001 TypeScript Tools for Microsoft Visual Studio

Uno Platform Extension 1.0 Uno Platform Extension to create cross-platform apps using iOS, Android, mac Catalyst, Skia and WebAssembly.

Visual Basic Tools 4.8.0-7.23572.1+7b75981cf3bd520b86ec4ed00ec156c8bc48e4eb Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Visual F# Tools 17.8.0-beta.23475.2+10f956e631a1efc0f7f5e49c626c494cd32b1f50 Microsoft Visual F# Tools

Visual Studio IntelliCode 2.2 AI-assisted development for Visual Studio.

VisualStudio.DeviceLog 1.0 Information about my package

VisualStudio.Mac 1.0 Mac Extension for Visual Studio

VSPackage Extension 1.0 VSPackage Visual Studio Extension Detailed Info

Xamarin 17.8.0.156 (d17-8@bd02f18) Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin Designer 17.8.3.6 (remotes/origin/d17-8@eccf46a291) Visual Studio extension to enable Xamarin Designer tools in Visual Studio.

Xamarin.Android SDK 13.2.2.0 (d17-5/45b0e14) Xamarin.Android Reference Assemblies and MSBuild support. Mono: d9a6e87 Java.Interop: xamarin/java.interop/d17-5@149d70fe SQLite: xamarin/sqlite/3.40.1@68c69d8 Xamarin.Android Tools: xamarin/xamarin-android-tools/d17-5@ca1552d

Xamarin.iOS and Xamarin.Mac SDK 16.4.0.23 (9defd91b3) Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.

System Info

OS Name Microsoft Windows 11 Enterprise Version 10.0.22631 Build 22631 Other OS Description Not Available OS Manufacturer Microsoft Corporation System Name [my machine name here] System Manufacturer Parallels International GmbH. System Model Parallels ARM Virtual Machine System Type ARM64-based PC System SKU Parallels_ARM_VM Processor Apple Silicon, 3200 Mhz, 1 Core(s), 1 Logical Processor(s) Processor Apple Silicon, 3200 Mhz, 1 Core(s), 1 Logical Processor(s) Processor Apple Silicon, 3200 Mhz, 1 Core(s), 1 Logical Processor(s) Processor Apple Silicon, 3200 Mhz, 1 Core(s), 1 Logical Processor(s) Processor Apple Silicon, 3200 Mhz, 1 Core(s), 1 Logical Processor(s) Processor Apple Silicon, 3200 Mhz, 1 Core(s), 1 Logical Processor(s) BIOS Version/Date Parallels International GmbH. 19.2.1 (54832), Not Available SMBIOS Version 3.0 Embedded Controller Version 255.255 BIOS Mode UEFI BaseBoard Manufacturer Parallels ARM Virtual Machine BaseBoard Product Parallels ARM Virtual Platform BaseBoard Version 0.1 Platform Role Slate Secure Boot State On PCR7 Configuration Elevation Required to View Windows Directory C:\Windows System Directory C:\Windows\system32 Boot Device \Device\HarddiskVolume2 Locale United States Hardware Abstraction Layer Version = "10.0.22621.2506" User Name [my machine name here]\ben Time Zone US Mountain Standard Time Installed Physical Memory (RAM) 48.0 GB Total Physical Memory 40.0 GB Available Physical Memory 28.9 GB Total Virtual Memory 42.5 GB Available Virtual Memory 31.2 GB Page File Space 2.50 GB Page File C:\pagefile.sys Kernel DMA Protection Off Virtualization-based security Not enabled Windows Defender Application Control policy Enforced Windows Defender Application Control user mode policy Off Device Encryption Support Elevation Required to View A hypervisor has been detected. Features required for Hyper-V will not be displayed.

[christianfo]

@baskren, that indeed creates a project that builds, I can add the following in the project file:

    <PackageReference Include="Microsoft.Identity.Client" />
    <PackageReference Include="Uno.WinUI.MSAL" />

with their PackageVersion counterparts in Directory.Packages.props

    <PackageVersion Include="Microsoft.Identity.Client" Version="4.58.1" />
    <PackageVersion Include="Uno.WinUI.MSAL" Version="5.0.41"/>

However, as soon as I add my OneDrive.cs code that calls into Microsoft.Identity.Client and Uno.WinUI.MSAL, I get the same error again:

2>C:\Program Files\dotnet\sdk\8.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.ConflictResolution.targets(112,5): error NETSDK1152: Found multiple publish output files with the same relative path: 
C:\uno\UnoMsalTest\UnoMsalTest.Windows\obj\x64\Debug\net7.0-windows10.0.19041.0\win-x64\MsixContent\Microsoft.Web.WebView2.Core.dll,
C:\Users\[username]\.nuget\packages\microsoft.web.webview2\1.0.864.35\lib\netcoreapp3.0\Microsoft.Web.WebView2.Core.dll.

[baskren]

Hmmm. This is a long shot but what happens if you remove the <PackageVersion Include="Microsoft.Identity.Client" Version="4.58.1" /> and just keep the <PackageVersion Include="Uno.WinUI.MSAL" Version="5.0.41"/>?

[christianfo]

No difference. Same error. Also, afaict, your VS and System infos are very similar to mine. I tried deleting the NuGet local caches on my machine, but that did not change anything either.

[baskren]

... and you've done a dotnet tool update -g uno.check and then command line run uno-check recently, too, I'm guessing?

[christianfo]

I had uno.check 1.17.0, just updated to 1.18.1 (latest), closed VS, reran uno-check, restarted VS, but getting same error.

[christianfo]

FWIW, here is the app you suggested I built: UnoMsalTest.zip

[baskren]

@christianfo :

OK, I think you're right in thinking it's something in your build environment. I just built the two apps you shared earlier and they both worked!

So, I only have one more suggestion. Spin up and new VM, install VisualStudio 2022, install the Uno Platform extension for VisualStudio, run uno-check, and try again. If that works, then it really is your machine's environment.

[christianfo]

Will do. I was also installing latest VS and Uno platform on another machine. Will let you know what I learn.

As a curiosity, could you tell me what Microsoft.Web.WebView2 package(s) you have on your machine. Given that the error appears to be complaining about the MSIX build and the app build trying to deploy the Microsoft.Web.WebView2.Core.dll file to the same location, I was thinking this might have to do with the state of the WebView2 packages on our respective machines.

[baskren]

• In my ~/.nuget/Packages/microsoft.web.webview2/ folder, I only have the 1.0.864.35 folder.
• In C:\Program Files (x86)\Microsoft SDKs\NuGetPackages, I don't have a microsoft.web.webview2 folder

Not sure if there's another system reference to WebView2 in the environment that wouldn't be controlled by the <PackageReference ... /> items we used in our .csproj files.

[christianfo]

Thanks, I have the same on my machine.

[christianfo]

I just finished installing on my second machine (laptop) and I am getting the same error.

[christianfo]

As a data point, if I disable MSIX Tooling:

<PropertyGroup>
  <EnableMsixTooling>false</EnableMsixTooling>
</PropertyGroup>

and build the Unpackaged target, it builds.

(My real app had dependencies on being a packaged app, so this is hardly a work around for me, but it does confirm this has something to do with the MSIX packaging part of the build)

[baskren]

Interesting. I thought I was building for packaged. I’ll have to confirm if I was or not. I know I “Packaged and publish” as MSIX to test if it worked.

I’ll take a closer look at all this tomorrow.

[baskren]

One more thing. Do you have the Visual Studio “MSIX packaging extension” installed?

[christianfo]

I have the "Single-project MSIX Packaging Tools for VS 2022" installed.

[baskren]

I was able to confirm that I was using "packaged" app builds and that I was able to generate MSIX files.