Unable to use in a WinUI 3 in Desktop project

[nxtn-staged]

Describe the bug

When used in a WinUI 3 in Desktop project, the Microsoft.UI.Xaml 2.7.0 dependency is picked up so the app is unable to load the correct version of Microsoft.UI.Xaml.dll.

https://github.com/CommunityToolkit/Labs-Windows/blob/97104bd68136a3b24f13daae04d8a6b0231eb873/common/Labs.MultiTarget.props#L32

I can get around this by removing the UWP TFM.

https://github.com/CommunityToolkit/Labs-Windows/blob/97104bd68136a3b24f13daae04d8a6b0231eb873/common/Labs.MultiTarget.props#L11

Steps to reproduce

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net6.0-windows10.0.19041.0</TargetFramework>
    <TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion>
    <RootNamespace>Test.WinUI</RootNamespace>
    <ApplicationManifest>app.manifest</ApplicationManifest>
    <Platforms>x86;x64;arm64</Platforms>
    <RuntimeIdentifiers>win10-x86;win10-x64;win10-arm64</RuntimeIdentifiers>
    <UseWinUI>true</UseWinUI>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.WindowsAppSDK" Version="1.1.3" />
    <PackageReference Include="Microsoft.Windows.SDK.BuildTools" Version="10.0.22000.194" />
    <Manifest Include="$(ApplicationManifest)" />
    <PackageReference Include="CommunityToolkit.Labs.WinUI.SettingsControls" Version="0.0.1" />
  </ItemGroup>
</Project>

Expected behavior

None.

Screenshots

Code Platform

• [ ] UWP
• [X] WinAppSDK / WinUI 3
• [ ] Web Assembly (WASM)
• [ ] Android
• [ ] iOS
• [ ] MacOS
• [ ] Linux / GTK

Windows Build Number

• [ ] Windows 10 1809 (Build 17763)
• [ ] Windows 10 1903 (Build 18362)
• [ ] Windows 10 1909 (Build 18363)
• [ ] Windows 10 2004 (Build 19041)
• [ ] Windows 10 20H2 (Build 19042)
• [ ] Windows 10 21H1 (Build 19043)
• [X] Windows 11 21H2 (Build 22000)
• [ ] Other (specify)

Other Windows Build number

No response

App minimum and target SDK version

• [X] Windows 10, version 1809 (Build 17763)
• [ ] Windows 10, version 1903 (Build 18362)
• [ ] Windows 10, version 1909 (Build 18363)
• [X] Windows 10, version 2004 (Build 19041)
• [ ] Other (specify)

Other SDK version

No response

Visual Studio Version

Preview

Visual Studio Build Number

No response

Device form factor

Desktop

Additional context

No response

Help us help you

Yes, but only if others can assist.

[michael-hawker]

@Arlodotexe we tested this, are the packages in the feed just out-of-date? I know we ran into issues as #211 hasn't been merged, and the intent was for that to bump and regenerate the packages.

@nxtn-staged were you using a specific component from the feed (which package)? Removing the TFM just means it's not including the UWP version at all.

[nxtn-staged]

were you using a specific component from the feed (which package)? Removing the TFM just means it's not including the UWP version at all.

Hi @michael-hawker, I've tried both a PackageReference to CommunityToolkit.Labs.WinUI.SettingsControls 0.0.1 in the feed, and a ProjectReference to labs/SettingsControls/src/CommunityToolkit.Labs.WinUI.SettingsControls.csproj in the latest master.

[Richasy]

@michael-hawker @niels9001 This problem can be reproduced in the Windows App SDK of the Windows application packaging project. In a blank project As long as the nuget package is installed, an error will be throw when running the project. The problem cannot be reproduced in the self-container project.

[niels9001]

@Arlodotexe @michael-hawker Able to reproduce this.. seems to be happening for all Labs packages, so not only SettingsControls. 7.x packages work fine.

Repro here: https://github.com/niels9001/LabsErrorRepro

[michael-hawker]

Was able to build on the command line with:

msbuild /restore /bl /property:Platform=x64

In the binlog it clearly shows the DoubleWrite occuring when copying output:

I looked at the Windows App SDK package and noticed they have a UAP lib folder here:

I wonder if a packaged app registers as a UAP target framework, and therefore it's picking up the UWP dependency from our NuGet package?

Easiest solution may just be to remove the UAP target from the WinUI based NuGet packages anyway...?

I'm going to follow-up with the Windows App SDK team to see if this hypothesis is correct, and if so, I can easily update our build CI process with our existing script helpers.

[michael-hawker]

Alright, I built things locally with what I was fiddling with in #350, but that requires more finesse to make that a solid PR in the future (better sln gen tooling for us in labs).

I have confirmed with a locally built NuGet package that doesn't contain the UWP TFM:

That the packaged desktop app can now run fine without the old WinUI 2 dll being copied over. (Accidently ran the unpackaged head at first and got the same error, so was confused at first...oops.)

Still waiting to hear back from platform on expected behavior but seems like this is most likely the path for us.

Ideally, with this path we:

• Have our CommunityToolkit.[Labs].Uwp.* package which:
  • doesn't include the Windows App SDK bits
  • Means we don't/can't run WinAppSDK tests
  • Means we need to remove the WinAppSDK sample app head
• Have our CommunityToolkit.[Labs].WinUI.* package which:
  • doesn't include the UWP bits
  • Means we don't/can't run UWP tests
  • Means we need to remove the UWP sample app head
• Locally though we want to target everything and have all heads enabled to allow for building, testing, and running samples for either UWP or the WinAppSDK.
• This also have the benefit of reducing some of the duplication that's occurring in our CI currently with respect to UWP and the Windows App SDK for sample heads and tests.
• Ideally, we split out how things get built between the libraries, the tests, and the sample heads to better parallelize our CI as well.
• Our messaging doesn't change as we were still expecting to have two package lines for Uno.UI/Uno.WinUI anyway. UWP devs use the Uwp packages, WinAppSDK devs use the WinUI packages. All have the same namespace, so whenever you migrate, the only thing required is changing the package pulled.

Think that's everything?

[niels9001]

@Arlodotexe @michael-hawker

I was still getting this error:

Deleting the Microsoft.UI.Xaml NuGet packages however made it go away - is this intended behavior? Would that be resolved automagically if we upgrade to WinUI v2.8.x?

[michael-hawker]

@niels9001 we didn't re-rev the packages, so we need to do that and ship new versions of them all. Want to open a new PR to just rev the versions of all experiments in the repo? That should hopefully fix it.

[michael-hawker]

New WinUI packages should be shipped to the Labs feed, so hopefully this is resolved now. 🤞