Add support for Microsoft.WindowsAppSDK.Foundation bootstrapper

[mschofie]

The Microsoft.WindowsAppSDK.Foundation NuGet package contains MSBuild/headers/source code/libs/dlls for 'bootstrapping' aspects of the Windows App SDK. This PR is to have a discussion as to how the support is surfaced.

A couple of points to discuss:

1. There's a little awkwardness around Microsoft.WindowsAppSDK.Runtime. The Microsoft.WindowsAppSDK.Foundation NuGet doesn't depend on the Microsoft.WindowsAppSDK.Runtime NuGet, but the bootstrapper code needs the WindowsAppSDK-VersionInfo.h from the Microsoft.WindowsAppSDK.Runtime NuGet. As a result, the CMake logic here checks to see if the Microsoft.WindowsAppSDK.Runtime CMake package is available, and only if it is, creates the Microsoft.WindowsAppSDK.Foundation_FrameworkBootstrap target. I couldn't find analogous logic in the MSBuild scripts, so I'm not really sure how it's handled.

2. This PR specifically adds support for the WindowsAppSdkBootstrapInitialize-controlled bootstrap. It would be great to understand options for other MSBuild properties. There are four MSBuild properties that control the behavior of the bootstrapper:

   • WindowsAppSdkBootstrapInitialize
   • WindowsAppSdkDeploymentManagerInitialize
   • WindowsAppSdkUndockedRegFreeWinRTInitialize
   • WindowsAppSdkCompatibilityInitialize

   How should they be surfaced? Should there be CMake variables to control what the Microsoft.WindowsAppSDK.Foundation_FrameworkBootstrap target represents? That seems reasonable, but it does mean that - AFAICT - the behavior of the Microsoft.WindowsAppSDK.Foundation_FrameworkBootstrap target would be 'fixed' for the scope of the whole CMake build. This means that you couldn't - for example - build one .exe that is framework-dependent and one that isn't. Since MSBuild re-evaluates the MSBuild-logic on a per-project basis, you can change the behavior of the compiled .cpp on a per-project basis.

   The alternative would be to create the necessary set of individual targets that represent the options. Which would be a little verbose/noisy.

Thoughts?

I pushed a small self-contained buddy test here incase folks want to try things out.

[Copilot]

Pull request overview

Adds CMake overlay support for the Microsoft.WindowsAppSDK.Foundation NuGet package’s “framework bootstrapper” scenario by introducing new convenience targets and conditionally exposing a bootstrap target when Microsoft.WindowsAppSDK.Runtime is available.

Changes:

• Adds Microsoft.WindowsAppSDK.Foundation_Framework as an INTERFACE convenience target.
• Conditionally defines Microsoft.WindowsAppSDK.Foundation_FrameworkBootstrap when Microsoft.WindowsAppSDK.Runtime can be found, wiring in bootstrapper sources/defines and linking to the bootstrap DLL/implib.
• Leaves existing ..._SelfContained behavior intact.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Spelling: comment says "bootrap"; should be "bootstrap" (also helps searchability for users scanning the file).

Suggested change

	target will not be created, and the end-user will need to bootrap the Framework manually.
	target will not be created, and the end-user will need to bootstrap the Framework manually.

[Copilot]

Microsoft.WindowsAppSDK.Foundation_FrameworkBootstrap doesn't link to Microsoft.WindowsAppSDK.Foundation/..._Framework, so consuming projects that link only this target won't get the Foundation projection/include dirs. For consistency with existing *_Framework/*_SelfContained targets (which include their base target), consider linking this target against Microsoft.WindowsAppSDK.Foundation_Framework (or Microsoft.WindowsAppSDK.Foundation) as an INTERFACE dependency.

Suggested change

	Microsoft.WindowsAppSDK.Runtime
	Microsoft.WindowsAppSDK.Runtime
	Microsoft.WindowsAppSDK.Foundation

[jonwis]

Seems pretty reasonable. App "targets" the framework & bootstrapper. Is it an error to target _frameworkbootstrap without _framework ?