Use slngen and remove UWP target from WinUI packages

[michael-hawker]

Fixes dotnet/runtime#262
Fixes dotnet/runtime#257

With this change UWP developers will have to use the CommunityToolkit.Labs.Uwp.* packages and WindowsAppSDK developers will need to use CommunityToolkit.Labs.WinUI packages (as we've been communicating already, so no change there).

We thought we may be able to ease transition by including both by still including UWP bits in the WinUI packages, but dotnet/runtime#262 may indicate that breaks when building a Packaged Windows App SDK Desktop project.

This PR removes the UWP bits from the WinUI NuGet packages (they remain of course in the UWP NuGet packages).

It also:

• Uses slngen Fixing Dragon4 to take unbiased rounding into account. dotnet/runtime#257 to build the solution file and be able to better selectively include sample/test projects for UWP/WinAppSDK as needed for the changes to fix Remove references to gender dotnet/runtime#262.
  • Currently can't build for ARM64, have issue open with slngen: ARM/ARM64 not supported as values to --platform flag microsoft/slngen#437 (will fix forward later)
• Adds a 'all-uwp' target to UseTargetFrameworks.ps1 (simplifies the CI, especially if we add or change platform target identifiers)
• Adds better documentation to UseTargetFrameworks.ps1 (@Arlodotexe we should do the longform help for all the scripts as we update them so they show-up with Get-Help in PowerShell and better document what they do and how they work)

Before:

After (-detailed will show parameter help):

• And of course, conditionally selects the set of platforms to build for in the CI based on if running the UWP or WinUI package job

Opening this draft PR to test while we await more info on expected behaviors from the platform team.

[michael-hawker]

Write the UWP test head...

D:\a\Labs-Windows\Labs-Windows\tests\CommunityToolkit.Labs.Tests.Uwp\CommunityToolkit.Labs.Tests.Uwp.csproj : error NU1605: Detected package downgrade: System.Reflection from 4.3.0 to 4.1.0. Reference the package directly from the project to select a different version.  [D:\a\Labs-Windows\Labs-Windows\Toolkit.Labs.All.sln]
D:\a\Labs-Windows\Labs-Windows\tests\CommunityToolkit.Labs.Tests.Uwp\CommunityToolkit.Labs.Tests.Uwp.csproj : error NU1605:  CommunityToolkit.Labs.Tests.Uwp -> Microsoft.NET.Test.Sdk 16.11.0 -> System.Runtime.InteropServices.RuntimeInformation 4.0.0 -> System.Resources.ResourceManager 4.0.1 -> runtime.aot.System.Resources.ResourceManager 4.3.0 -> System.Reflection (>= 4.3.0)  [D:\a\Labs-Windows\Labs-Windows\Toolkit.Labs.All.sln]

We wouldn't need to build or run those tests on the WinUI 3 build anymore (they're run on WinUI 2 one anyway).

🤔

[michael-hawker]

Hope this time works. VS may want to prompt to save sln file, so need to investigate later or clean-up this approach if we end up doing this... Just trying to get bits to see if resolve issue at first at least...

[michael-hawker]

Using this to test out and validate changes for dotnet/runtime#257 as well now.

[michael-hawker]

@Arlodotexe very weird, looks like rollForward didn't work on linux, as updating the version in the global.json worked fine... @jeromelaban any ideas why that may have been?

It clearly worked on Windows:

Wonder if it could be something like this issue? dotnet/sdk#13799

Will comment there and see.

[michael-hawker]

Updated PR description, think we're basically ready to go. Everything looks good in the CI.

[michael-hawker]

Checked everything still working with Codespaces as well. Haven't heard back on platform thread, will follow-up on Monday, but think we can move forward still as we know this resolves the issue.

[jeromelaban]

@Arlodotexe very weird, looks like rollForward didn't work on linux, as updating the version in the global.json worked fine... @jeromelaban any ideas why that may have been?

It does not ring a bell, no. It's been generally reliable for me, are you still having an issue?

[michael-hawker]

@jeromelaban saw it as an issue, added all of what I saw in a comment here: dotnet/sdk#13799 (comment)

(Looks like slngen has updated for ARM64, will push an update to the PR to check-out.)

[michael-hawker]

@Arlodotexe slngen was just updated, so this PR should be all set without further work.

Discussed with @azchohfi too that we only need ARM64 support and shouldn't need ARM.

[Arlodotexe]

Tested locally and everything works as expected. Before closing, we should remove the common/Toolkit.Labs.All.sln.template file since it's no longer being used.

[michael-hawker]

Thanks @Arlodotexe, good catch! Have pushed a commit to remove the file. Will make sure everything runs clean again and then merge.

[michael-hawker]

Well now I'm extra confused... it says the .NET SDK is installed, but then it can't find it???

@jeromelaban think I should open an issue on the https://github.com/actions/runner-images repo for this? I don't really understand why it's failing to find the SDK in one tool, when the install tool finds it fine... Any ideas? Like it just ran fine in the previous commit 4601457, and nothing that effects it should have changed.

[michael-hawker]

Um... the WinUI 3 build failed with the same issue... what???

[michael-hawker]

As far as we can tell when this occurs it doesn't seem to be hitting slngen, or if it is, it's before any of their logging is occuring.

The -d flag to dotnet also doesn't seem to provide any extra information.

Explicitly listed the sdks again, and we can clearly see it's just confused:

Which makes no sense. Not sure where to follow-up from here. Also, not sure why this just happened to start occurring in the last day or so, as we did have clean builds before.

It seems to consistently fails on Linux in the CI (Ubuntu), but works in Codespaces (Debian).

It seems intermittent on if it fails on Windows...

[michael-hawker]

So, pretty sure this issue is specific to the dotnet tool and how it handles global.json.

I removed our global.json pin:

{
  "sdk": {
    "version": "6.0.405",
    "rollForward": "latestFeature"
  },

And then it picked up the .NET 7 install and ran fine.

I added it back, but without the rollForward parameter:

{
  "sdk": {
    "version": "6.0.405"
  },

And then it properly picked up the request and installed 6.0.405 version of .NET...

So, it seems like rollForward is just broken?

[michael-hawker]

Filed dotnet/sdk#30361 but think it's related to not using tool run explicitly when calling slngen. Will clean-up in morning and get us back to where we were with the PR when it was ready to merge, with new fix. And hopefully we should be good? Very bizarre. FYI @jeromelaban, we were using tool run for our other tools, but could see this be a general issue, as far as we saw the tool was never run, so should be a general problem, but hopefully an easy workaround?