-
Notifications
You must be signed in to change notification settings - Fork 735
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Uno.WinUI.MSAL
and WindowsAppSDKSelfContained
clash
#14555
Comments
Feels similar to microsoft/microsoft-ui-xaml#8857 |
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:
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. |
Tried upgrading Uno packages from 5.0.118 to 5.1.0-dev.1108. That did not help. |
@jeromelaban, any pointer as to how to try to make a workaround? |
@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 UPDATE : No, didn't work. Nor did going into the <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! |
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. |
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. |
@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 |
@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. |
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. |
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: Uno app (does not build for Windows, but builds for WASM and Android): |
OK, I believe that I've figured it out. Here is what I learned:
<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 |
@baskren, thank you! When I try to build the UnoMsalApp2 that you posted above, I still get the following error:
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. |
Both hypotheses sound mildly plausible. Just out of curiosity, what happens when you start with a fresh <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 InfoMicrosoft Visual Studio Community 2022Version 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 ASP.NET and Web Tools 17.8.358.6298 Azure App Service Tools v3.0.0 17.8.358.6298 Azure Functions and Web Jobs Tools 17.8.358.6298 C# Tools 4.8.0-7.23572.1+7b75981cf3bd520b86ec4ed00ec156c8bc48e4eb CleanBinAndObjCommand Extension 1.2.58 Extensibility Message Bus 1.4.39 (main@e8108eb) Microsoft JVM Debugger 1.0 NuGet Package Manager 6.8.0 Project System Tools 1.0 Razor (ASP.NET Core) 17.8.3.2358002+8c7fb27bf8e8d4f9ff8080b624b35bca5e812e97 SQL Server Data Tools 17.8.119.0 TypeScript Tools 17.0.20920.2001 Uno Platform Extension 1.0 Visual Basic Tools 4.8.0-7.23572.1+7b75981cf3bd520b86ec4ed00ec156c8bc48e4eb Visual F# Tools 17.8.0-beta.23475.2+10f956e631a1efc0f7f5e49c626c494cd32b1f50 Visual Studio IntelliCode 2.2 VisualStudio.DeviceLog 1.0 VisualStudio.Mac 1.0 VSPackage Extension 1.0 Xamarin 17.8.0.156 (d17-8@bd02f18) Xamarin Designer 17.8.3.6 (remotes/origin/d17-8@eccf46a291) Xamarin.Android SDK 13.2.2.0 (d17-5/45b0e14) Xamarin.iOS and Xamarin.Mac SDK 16.4.0.23 (9defd91b3) System InfoOS Name Microsoft Windows 11 Enterprise |
@baskren, that indeed creates a project that builds, I can add the following in the project file:
with their
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:
|
Hmmm. This is a long shot but what happens if you remove the |
No difference. Same error. |
... and you've done a |
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. |
FWIW, here is the app you suggested I built: |
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. |
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 |
Not sure if there's another system reference to WebView2 in the environment that wouldn't be controlled by the |
Thanks, I have the same on my machine. |
I just finished installing on my second machine (laptop) and I am getting the same error. |
As a data point, if I disable MSIX Tooling:
and build the (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) |
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. |
One more thing. Do you have the Visual Studio “MSIX packaging extension” installed? |
I have the "Single-project MSIX Packaging Tools for VS 2022" installed. |
I was able to confirm that I was using "packaged" app builds and that I was able to generate MSIX files. |
Thanks @baskren and happy New Year! |
I still don't understand why this fails for me and works on @baskren's machine, but I managed to create a patch to work around the problem and build and run successfully. Sharing in case this is useful to others. Just add the following to your windows project:
|
@christianfo : WOW! Based upon the content of your work around, you must have really put in some time. Thank you! Next week I am going to be working on a new project that requires developing from a Windows 10 laptop. In that past I know I had this issue on that device and haven't had a chance to see if it's still present. I'm guessing that you might have just made my life a lot easier next week! |
@baskren, yes it took me a little while :). But it's nice to be able to get past this! Definitely let me know if this works for you! |
@christianfo the workaround is indeed working properly, thanks! I'm not sure where this workaround should live, and what the cause of this is. This feels like |
@jeromelaban, yes, this is likely something for the WinUI or the Edge team to fix. Let me know if I can help follow up with them. This is definitely only a temporary workaround. Future changes in the WinUI3 build system could easily break it. |
I tried to upgrade to Windows App SDK 1.5.240205001-preview1 and I am getting another similar conflict now:
Probably time to augment the workaround... |
@christianfo for that particular error, you may try removing the workaround, as microsoft/microsoft-ui-xaml#8857 got fixed. |
@christianfo : FWIW, after my virgin project got complicated, this problem appeared. Your work around worked! |
The workaround used to be effective previously. However, ever since we upgraded WinAppSDK to version 1.5.X, it no longer functions properly for publishing. |
As an update, microsoft/WindowsAppSDK#4249 is being tracked to resolve this issue. Uno has a workaround integrated when referencing Uno.Extensions.Authentication.MSAL (from unoplatform/uno.extensions#2205). The workaround here #14555 (comment) is still applicable for WinAppSDK 1.5.240404000. |
I have found a workaround that made my project work here: |
For those still experiencing an error: |
Thank you for this @christianfo! Saved us a lot of hassle. Can i also echo the disappointment of others that this issue has been open so long both here and in its other various guises:
|
Fixed by microsoft/WindowsAppSDK#4249 |
Current behavior
After adding
Uno.WinUI.MSAL
and setting<WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>
in Windows.csproj
, build fails with: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
The text was updated successfully, but these errors were encountered: