Add multi-headed MSIX package sample apps - experimental

[guimafelipe]

Summary

• Adds two sample apps under Samples/MultiHeadedPackage/ demonstrating multiple <Application> elements in a single package manifest
• cs-winui-msix: WinUI 3 primary app + console secondary app packaged together in one MSIX via single-project packaging
• cs-wpf-sparse: WPF primary app (with register/unregister/restart UI) + WPF secondary app in one sparse package

These samples support the multi-headed MSIX packaging feature added in WindowsAppSDK (microsoft/WindowsAppSDK#5586).

Description

Multi-headed packages contain multiple <Application> entries in a single Package.appxmanifest. Each application gets its own Start menu tile and can be launched independently, while sharing the same package identity and installation lifecycle.

The MSIX sample uses single-project MSIX packaging. The primary WinUI app owns the manifest and uses $targetnametoken$ tokens. The secondary console app is included via <ProjectReference> with its executable hardcoded in the manifest as SecondaryApp.exe with EntryPoint="Windows.FullTrustApplication". After deployment, both apps appear as separate Start menu entries.

The sparse sample demonstrates the same multi-headed pattern with runtime-registered sparse packages. The primary WPF app provides Register/Unregister/Restart buttons using PackageManager.AddPackageByUriAsync. The secondary WPF app uses GetCurrentPackageFullName to detect whether it has package identity, which it will once the sparse package is registered.

[ssparach]

Consider not checking the certificate into the sample. For sparse packaging, a similar approach to WindowsAIFoundry/cs-wpf-sparse can be followed, where a PowerShell script is used to create a development signing certificate if one does not already exist.

[guimafelipe]

Their powershell script is not run by the pipeline as they are not using MSIX build tools for that sample.

Our sample is using MSIX build tools (by setting EnableMsixTooling=true and WindowsPackageType=Sparse.

On our code, the targets would error out if the cert is not present as it automatically tries to create and sign the msix package during the build.

If we remove the msix buid tools, we would not be testing our build system at all.

The certificate is just a test one generated with no password and I don't think it would be a security concern. Generating them through powershell script is just another layer of complexity.

[ssparach]

Consider adding explicit package versions here as well

[guimafelipe]

The samples will not build with explicit package versions. They are defined by the repository here https://github.com/microsoft/WindowsAppSDK-Samples/blob/release/experimental/Samples/Directory.Packages.props

[lauren-ciha]

I'm excited to see these changes go in. Before we do, let's get the samples building in VS and follow up on Sarah's cert concern.

[lauren-ciha]

I noticed .NET 6 is out of support. Do we want to update it to a higher version (here and in SecondaryApp.csproj?

[lauren-ciha]

This is consistent with the other samples. If we update the dotnet version for this, we should update all of them to the minimum supported version.

[lauren-ciha]

Is the exe name hardcoded here to prevent collisions or some other reason?

[guimafelipe]

It is hardcoded because the build system only automatically updates the "header project" values. For the other projects, we need to hardcode the names. This is similar to WAP experience. It is in my backlog to add a feature to fill in the Application fields automatically from the referenced projects.

[lauren-ciha]

F5 builds aren't currently supported. When I build and run in VS (2026), I get this error:

{PathToSamplesRepo}\Samples\MultiHeadedPackage\cs\cs-winui-msix\PrimaryApp\Properties\launchSettings.json was not found. To debug a packaged single-project MSIX solution, a profile with command name MsixPackage in launchSettings.json is required. For more information, visit https://aka.ms/winappsdk.singleproj.

This error is in {pathToDotNuget}\.nuget\packages\microsoft.windowsappsdk.base\1.8.250831001\buildTransitive\Microsoft.WindowsAppSDK.SingleProject.targets, so we'll need to update the Single-project MSIX VSIX to support this as well.