Switch gallery to use experimental self-contained WinAppSDK and showcase new windowing APIs

[Jesse Collins (JesseCol)]

This content was largely generated by AI. AI makes mistakes.

Description

Make Gallery use an experimental WinAppSDK build

• Target Windows App SDK 2.4.1-experimental with the normal Debug/Release configurations. Bundle WinAppSDK with Gallery and the unit-test host using self-contained deployment.
• Fix VersionHelper startup failures by reading SDK-generated version information instead of querying the framework-only Insights resource DLL. Show the SDK channel on Home and Settings, including Windows App SDK 2.4 (experimental), and update the regression test.
• Remove the incorrect App Notifications warning about Singleton-package requirements and self-contained deployment.
• Document the experimental SDK dependency. NativeAOT remains disabled.

Showcase the new windowing APIs

• Combine stable window creation and experimental sizing on the Windowing APIs page. The stable example retains AppWindow.ResizeClient(); the other examples demonstrate Window.Width, Height, MinWidth, MinHeight, MaxWidth, and MaxHeight.
• Provide concise C# examples and equivalent XAML property declarations in the usual sample tabs. The selected size options update both versions.
• Use per-example experimental labels and warnings on this mixed page, while retaining page-level tagging support for entirely experimental pages. This builds on Adds experimental tags to samples #2230 and Allows individual samples to be marked experimental #2231; the PagerControl sample is not included.
• Keep TabView and AppWindow examples, including the modal sample, on their original APIs. The former Create Multiple Windows example moves to the combined page without changing its sizing API.
• Use the new properties internally in MainWindow for minimum sizing and persistence across launches, supporting packaged and unpackaged storage.
• Remove the unused native min/max sizing shim, while retaining the helper still needed by the existing TabView sample.

Motivation and Context

Gallery should demonstrate upcoming WinUI features while clearly distinguishing experimental examples from stable guidance. Shared tags support both entirely experimental pages and mixed pages with individually marked examples.

Self-contained deployment avoids a dependency on an experimental WinAppSDK framework package. It does not change the experimental SDK's support status or guarantee Store certification.

The Windowing examples distinguish the physical pixels accepted by AppWindow.ResizeClient() from the display-scaled client dimensions used by the experimental Window sizing properties.

How Has This Been Tested?

Windows x64, Visual Studio 2022, .NET 9, WinAppSDK 2.4.1-experimental.

• UI tests: passed locally on an earlier revision (Jesse's run); not rerun after the combined-page and maximum-size changes.
• Unit tests: one reported Canvas test failure due to missing GalleryTileGridStyle, which appears unrelated; that test and its resource setup are unchanged from main. The VersionHelper regression passed separately.
• Build/package: the Debug/x64 solution built after integrating Allows individual samples to be marked experimental #2231; the app also builds after the snippet updates and PagerControl removal. An earlier Release MSIX bundled the runtime without a WinAppSDK framework dependency.
• Window behavior/snippets: main-window persistence, minimum sizing, and version display were checked at 100% scaling. All 256 minimum/maximum combinations include the initial size; XAML and C# size values match across all dropdown combinations. Jesse reviewed the combined page locally; screenshot below.

Not tested: latest maximum-size interactions, multi-monitor DPI transitions, clean-machine installation, or Store certification. The unrelated test-host resource fix is not included in this PR.

Screenshots (if appropriate):

Combined Windowing APIs page, captured locally by Jesse:

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)