Upgrade to Windows App SDK 1.8

[Arlodotexe]

Background

Originally posted in the Windows App Community Discord server in #community-toolkit.

A few relevant links:

• GitHub release: https://github.com/microsoft/WindowsAppSDK/releases/tag/v1.8.0
• Wasdk 1.6 dependencies (our current version): https://www.nuget.org/packages/Microsoft.WindowsAppSDK/1.6.250602001#dependencies-body-tab
• Wasdk 1.8 dependencies (new version): https://www.nuget.org/packages/Microsoft.WindowsAppSDK/1.8.250907003#dependencies-body-tab

@0x5bfa mentioned the metapackage part of the release notes:

The Windows App SDK NuGet package has been converted to a NuGet metapackage. Each component contributing to the Windows App SDK is now a component NuGet package and is listed as a dependency by the metapackage. This allows developers to choose either the metapackage or select specific component packages for their applications.

Problem

Looking at the dependencies on 1.8 versus our current 1.6 version, we see:

Microsoft.WindowsAppSDK.AI (= 1.8.37)
Microsoft.WindowsAppSDK.Base (= 1.8.250831001)
Microsoft.WindowsAppSDK.DWrite (= 1.8.25090401)
Microsoft.WindowsAppSDK.Foundation (= 1.8.250906002)
Microsoft.WindowsAppSDK.InteractiveExperiences (= 1.8.250906004)
Microsoft.WindowsAppSDK.Runtime (= 1.8.250907003)
Microsoft.WindowsAppSDK.Widgets (= 1.8.250904007)
Microsoft.WindowsAppSDK.WinUI (= 1.8.250906003)

There's both new things here (AI), and there's existing code extracted into transitive package dependencies. The toolkit doesn't need to depend on most of these!

Solution

To determine which of these transitive packages we do need to depend on, we'd either need a namespace map or we'd need to invidually (manually) check what they do and if/where we depend on them throughout the toolkit.

Notably, Microsoft.WindowsAppSDK.WinUI depends on:

Microsoft.WindowsAppSDK.Base (>= 1.8.250831001)
Microsoft.WindowsAppSDK.Foundation (>= 1.8.250906002)
Microsoft.WindowsAppSDK.InteractiveExperiences (>= 1.8.250906004)

Which means we'll be pulling in these ambiguous ones anywhere we depend on WinUI-- this should cover the majority of toolkit components.

It might be enough to just replace our reference to Microsoft.WindowsAppSDK with a reference to Microsoft.WindowsAppSDK.WinUI. If that's not enough, we'll quickly learn why from the error.

[0x5bfa]

I’d love to work on it.

[Avid29]

I'll take a look

[Arlodotexe]

Looks like we stalled a bit when it came to opening the upstream PRs for Labs / mainline WCT for the submodule.

@Avid29 Happy to assign if you're willing to pick up where @0x5bfa left off.

We now only need to open PRs for both the Labs and the mainline WCT repos which bump the tooling submodule pointer to the WASDK 1.8 update PR. There, the CI would run the change against real components, and we'd be able to see and address any errors that come up for each.