Build winapp run projects with Platform instead of a global RID

[Nikola Metulev (nmetulev)]

Description

winapp run on a multi-project .NET app could fail to build even though the same solution builds in Visual Studio. FluentStore is a real example:

error APPX1101: Payload contains two or more files with the same destination path 'FluentStore.SDK.pdb'. Source files:
  ...\FluentStore.SDK\bin\arm64\Debug\net8.0-windows10.0.22621.0\FluentStore.SDK.pdb
  ...\FluentStore.SDK\bin\arm64\Debug\net8.0-windows10.0.22621.0\win-arm64\FluentStore.SDK.pdb

Cause: winapp passed a global -r win-<arch>, which Visual Studio never does.

• The Windows App SDK packaging targets (GetPriOutputs/GetPackagingOutputs) query project references without removing that RID.
• So a library without its own <RuntimeIdentifiers> that uses MSIX tooling is built twice, once with the RID and once without.
• Packaging then fails with APPX1101, PRI175/PRI252 or MSB3030, depending on the Windows App SDK version.

Fix: winapp run now passes the architecture as -p:Platform=<arch> only, as Visual Studio does. A project's own win-$(Platform).pubxml profile then applies without winapp choosing one. winapp first evaluates the app and every project it references with MSBuild, and keeps the previous RID-based behavior when:

• the app or a referenced project sets its own RuntimeIdentifier that isn't win-<arch> (a hard-coded RID, or win-$(Platform) with upper-case platform names). Such a project always gets -r win-<arch>; otherwise its own RID would win.
• the app or a referenced project enables EnableDynamicPlatformResolution.
• --arch differs from the .NET SDK's architecture and the reference graph includes an analyzer or source-generator project. With a global Platform, the generator would be built for the target architecture, and the compiler couldn't load it.
• it's given a -p:Platform that doesn't match --arch, or an exact -p RuntimeIdentifier.

winapp pack and winapp run --aot are unchanged. --no-build still finds output from earlier RID-based builds.

Usage Example

winapp run D:\FluentStore\FluentStore.App

Before:

dotnet build ...FluentStore.App.csproj -c Debug -r win-arm64 -v minimal -tl:off -p:Platform=arm64 ...
error APPX1101: Payload contains two or more files with the same destination path 'FluentStore.SDK.pdb'.
❌ Build failed for FluentStore.App.csproj (exit code 1).

After (observed):

dotnet build ...FluentStore.App.csproj -c Debug -v minimal -tl:off -p:Platform=arm64 ...
{ "AUMID": "52374YoshiAskharoun.FluentStore_7sdtne7r32rbe!App", "ProcessId": 91840 }

The app window ("Fluent Store") opened and was responding.

Related Issue

Related to #1035 (a separate launch hang found while building the test suite)

Type of Change

• 🐛 Bug fix
• 🧪 Test update

Checklist

• New tests added for new functionality (if applicable)
• Tested locally on Windows
• docs/usage.md updated (if CLI commands changed)
• Language-specific guides updated (if applicable)
• Sample projects updated to reflect changes (if applicable)
• Shipped skills updated in plugins/winapp/skills/ (if CLI commands/workflows changed)

Screenshots / Demo

N/A (CLI behavior; see the before/after output above).

Additional Notes

New automated test: tests/project-arch/ generates 66 small .NET projects and runs the real CLI on each. Each run checks that the build succeeds, that the expected architecture argument was used (Platform only, or the RID for the projects that need it), that the app launches and shows its own window (not an error dialog), and that the running executable matches --arch.

The projects cover:

• packaged, self-contained, unpackaged, WPF and console apps
• many project-reference shapes, including the FluentStore one, an app in a solution that builds an MSIX bundle on every build (bundling rebuilds the solution, which rejects a global RID with NETSDK1134), and an EnableDynamicPlatformResolution graph whose reference removes RuntimeIdentifier
• settings declared on a referenced project or through an import (Directory.Build.targets, $(…) paths)
• cross-architecture builds (--arch x86): source generators plus 12 common shapes
• tricky settings: publish profiles, a trimmed build with an AnyCPU library, PublishAot, a hard-coded RID
• Windows App SDK 1.6, 1.8 and 2.x

It runs in CI as the 4-shard project-arch job (which installs the x86 .NET runtimes and sets DOTNET_ROOT_X86 so unpackaged x86 apps can start):

• When: on every push to main and every manual run. On PRs, only when a small project-arch-changes job finds changes to project-mode build/run code, so docs-only PRs skip it.
• Gate: build-and-package accepts the matrix as skipped only when that check decided it wasn't needed.
• Against the pre-change CLI, the FluentStore-style projects fail, so the suite catches this regression.

Validation (arm64 dev machine):

Command	Result
.\scripts\build-cli.ps1 -SkipTests -SkipDocs	Passed
Invoke-Pester .\tests\project-arch\ProjectArch.Tests.ps1 (NativeAOT artifacts\cli)	64/64 passed; the 2 newest fixtures (R22, X04) pass separately
Review-fix fixtures (R17–R20, X01–X03) against the CLI before each fix and against v0.7.1	each failed before its fix (MSB3030, APPX1101, NETSDK1032/1083, CS0103); v0.7.1 builds them
winapp run on WinUI Gallery, AI Dev Gallery, FluentStore and 9 local test apps	all launch with a window, except one local app with an invalid manifest that fails the same way on v0.7.1
Same suite with the pre-change CLI, FluentStore-style projects	failed as expected (PRI175/PRI252)
R22 against v0.7.1	fails with NETSDK1134, the error reported on FluentStore's update/0.4.2 branch; passes on this PR
dotnet run --project src\winapp-CLI\WinApp.Cli.Tests -c Release -- --filter "...ProjectRun|RunCommand|PackageCommand"	913 passed, 1 skipped (long paths enabled on this machine)
.\scripts\build-cli.ps1 -OnlyTests -UseExistingArtifacts -TestSuite Core	7295 passed, 12 failed (see below)
Invoke-Pester scripts\tests\artifact-workflow.Tests.ps1	26/26 passed
.\scripts\test-samples.ps1 -Samples winui-app,winui-solution,winui-unpackaged-app,wpf-app,dotnet-app -WinappPath .\artifacts	51/51 passed
.\scripts\validate-llm-docs.ps1	Passed

About the 12 Core-suite failures:

• 11 are live nuget.org tests in NugetServiceTests, which can't reach nuget.org from this corporate machine (documented in AGENTS.md). They pass when pointed at the mirror via WINAPP_TEST_NUGET_SOURCE.
• 1 dump-analysis test (AnalyzeDumpAsync_ManagedDumpWithDeepStack_DetectsStackOverflowShape) failed: it read the dump's .NET runtime as x64, which doesn't match this arm64 host. The test is unrelated to this change.

Limitations:

• One cross-architecture generator case still fails: an app that declares <Platforms>, built for another architecture than the .NET SDK's. It fails the same way on v0.7.1 (CS0103, verified), because the RID-based path also passes a Platform there.
• Evaluating the reference graph adds one MSBuild evaluation per referenced project, up to 4 at a time: about 0.7 s for FluentStore's 8 projects.
• For the samples, I had to put the npm-installed CLI first on PATH, because this machine also has an older winapp MSIX installed.

[Copilot]

🟡 Changes recommended

The RID-required fallback can still suppress the RID for a split reference graph, reproducibly causing NETSDK1032.

1 open finding

• Fallback omits required RID after architecture override · New

What changed in this PR

Fixes multi-project winapp run builds by using MSBuild Platform instead of a global RID, with compatibility fallbacks and expanded regression coverage.

Changes:

• Adds Platform-only architecture resolution with RID fallbacks.
• Adds a generated 44-fixture architecture matrix and CI gate.
• Updates tests, samples, documentation, and plugin guidance.

File	Description
tests/​project-arch/​README.md	Documents the architecture matrix.
tests/​project-arch/​ProjectArch.Tests.ps1	Runs and validates generated fixtures.
tests/​project-arch/​ProjectArch.psm1	Generates fixture projects and executes the CLI.
src/​winapp-CLI/​WinApp.Cli/​Services/​ProjectRunService.Platform.cs	Resolves Platform-only versus RID builds.
src/​winapp-CLI/​WinApp.Cli/​Services/​ProjectRunService.cs	Integrates resolution and output fallbacks.
src/​winapp-CLI/​WinApp.Cli/​Models/​ProjectRunModels.cs	Updates architecture option contracts.
src/​winapp-CLI/​WinApp.Cli/​Commands/​RunCommand.cs	Updates architecture option help.
src/​winapp-CLI/​WinApp.Cli.Tests/​ProjectRunServiceTests.cs	Tests architecture resolution behavior.
src/​winapp-CLI/​WinApp.Cli.Tests/​ProjectRunServicePublishProfileTests.cs	Tests profile selection under Platform builds.
scripts/​tests/​artifact-workflow.Tests.ps1	Validates the new CI dependency.
samples/​winui-solution/​README.md	Updates multi-project behavior guidance.
samples/​winui-solution/​App.Core/​App.Core.csproj	Updates the regression explanation.
samples/​winui-app/​test.Tests.ps1	Tests Platform-based profile selection.
plugins/​winapp/​skills/​winapp-setup/​SKILL.md	Updates shipped setup guidance.
plugins/​winapp/​com.github.copilot/​agents/​winapp.agent.md	Updates agent command guidance.
docs/​usage.md	Documents revised option semantics.
docs/​guides/​dotnet.md	Updates multi-project build guidance.
AGENTS.md	Documents the architecture test workflow.
.github/​workflows/​build-package.yml	Adds the four-shard CI matrix.

🧠 Review effort: Balanced

---

Give feedback about Copilot approvals in this survey to enter a drawing for a $150 gift card.

[github-actions]

Build Metrics Report

Validation passed. All required build and validation jobs succeeded.

Binary Sizes

Artifact	Baseline	Current	Delta
CLI (ARM64)	57.77 MB	57.81 MB	📈 +39.0 KB (+0.07%)
CLI (x64)	57.79 MB	57.83 MB	📈 +37.5 KB (+0.06%)
MSIX (ARM64)	24.02 MB	24.04 MB	📈 +19.3 KB (+0.08%)
MSIX (x64)	25.49 MB	25.51 MB	📈 +16.9 KB (+0.06%)
NPM Package	50.08 MB	50.12 MB	📈 +42.6 KB (+0.08%)
NuGet Package	50.19 MB	50.23 MB	📈 +35.4 KB (+0.07%)

.NET Test Results (TRX reports)

Other suites are reflected in the overall validation status above.

✅ 8356 passed, 37 skipped out of 8393 tests in 1473.8s (+25 tests, +272.5s vs. baseline)

Test Coverage

✅ 87.5% line coverage, 82.3% branch coverage · ✅ no change vs. baseline

CLI Startup Time

66ms median (x64, winapp --version) · ⚠️ +24ms vs. baseline

Try This Build

Installs the MSIX for your architecture, replacing any previously installed build. Needs the GitHub CLI — the command offers to install it and sign you in if it is missing.

& ([scriptblock]::Create((irm https://raw.githubusercontent.com/microsoft/winappCli/main/scripts/winapp-pr.ps1))) 1032

Switching between builds often?

Put the tool on your PATH once:

& ([scriptblock]::Create((irm https://raw.githubusercontent.com/microsoft/winappCli/main/scripts/winapp-pr.ps1))) -AddToPath

Then this build is just:

winapp-pr 1032

Run winapp-pr with no arguments to pick from a list of open PRs.

---

Updated 2026-10-09 22:17:58 UTC · commit 97f9f66 · workflow run

[Zach Teutsch (zateutsch)]

🤖 AI-generated review (winappcli pr-review skill) — verify before acting.

Changes requested. The main fix works. I copied samples\winui-solution and ran winapp run WinUISolution.slnx with a published CLI from this branch on arm64. It built with -p:Platform=ARM64 and no -r, wrote output to bin\ARM64\Debug\<tfm>\, and registered and launched the app. The targeted unit tests (RunBuild, RunNoBuild, PublishProfile) pass 46/46.

I reproduced one regression against the released v0.7.1. Details are in the inline comment on ProjectRunService.Platform.cs; the fix is about two lines.

Must fix

• Projects that enable EnableDynamicPlatformResolution get -r win-<arch> added back, even where v0.7.1 had dropped it. A graph that reaches the same reference both with and without the RID then fails with MSB3030. v0.7.1 builds that graph successfully.

Non-blocking

• The new project-arch job runs on every PR and blocks build-and-package. See the inline comment on the workflow.

Not exercised: the full tests/project-arch suite and x64 or cross-arch runs. CI covers x64.

[Zach Teutsch (zateutsch)]

🤖 AI-generated review (winappcli pr-review skill) — verify before acting.

Changes requested. Thanks for the quick turnaround. Both earlier comments are fixed, and I checked them with a CLI published from 4e1984e5:

• R17-edpr-rid-split builds with -p:Platform=ARM64 only and succeeds.
• R16 still gets -r win-arm64, and R08 passes.
• The project-arch-changes gate is correct: the required check still fails if the filter job fails or is cancelled.
• Targeted unit tests pass (45/45), and artifact-workflow.Tests.ps1 passes (26/26).

Must fix: one new regression, which I reproduced against v0.7.1. Building for a different architecture than the machine now breaks apps that reference a source generator project. Details are in the inline comment.

Not exercised: an x64 host and the full tests/project-arch suite.

[Copilot]

🟡 Changes recommended

Referenced-project settings and imported analyzer references can bypass the RID fallback and cause reproducible build failures.

1 open finding

• Check transitive projects before selecting Platform-only builds · New

1 resolved since last review

• Fallback omits required RID after architecture override

🧠 Review effort: Balanced

[Zach Teutsch (zateutsch)]

🤖 AI-generated review (winappcli pr-review skill) — verify before acting.

Thanks for the cross-architecture generator fix. With the X01 layout, --arch x86 now keeps -r win-x86, builds an AnyCPU generator and compiles. The 283 ProjectRunService unit tests pass.

Two regressions against v0.7.1 remain, both shown at runtime with a published CLI from ac9e8790:

1. A property-path generator reference bypasses the new fallback. It still fails with CS0103 when the build targets another architecture.
2. The safety check only looks at the entry project. A referenced project that enables dynamic platform resolution fails with APPX1101, and one with a hard-coded conflicting RuntimeIdentifier fails with NETSDK1032. v0.7.1 builds both.

Details and smallest fixes are inline.

[Zach Teutsch (zateutsch)]

🤖 AI-generated review (winappcli pr-review skill) — verify before acting.

Thanks, evaluating the reference graph through MSBuild fixes the issues from the last review. I re-checked those shapes against npm v0.7.1 using a published CLI from 97f9f665:

• A referenced library with dynamic platform resolution builds.
• A referenced library with a hard-coded RID builds.
• R08 builds (it fails on v0.7.1).
• The property-path generator with --arch x86 builds an x86 exe.

The filtered ProjectRunService and MsBuildPropertyReader unit tests pass (432/432).

One regression against v0.7.1 remains. A reference marked ReferenceOutputAssembly="false" is skipped by the probe even though it is still built, so a conflicting RuntimeIdentifier in that project causes NETSDK1032. Details and the smallest fix are inline.

[Zach Teutsch (zateutsch)]

A build-order-only reference that sets its own RID still fails

• What is wrong: This branch treats every ReferenceOutputAssembly="false" reference as an analyzer and skips it with continue, so that project is never evaluated. But MSBuild still builds it, with the global Platform. If it sets its own RuntimeIdentifier, the probe never sees it and winapp picks a Platform-only build.
• Show me: Ran on arm64 with a CLI published from 97f9f665 and with npm v0.7.1:
  • Helper\Helper.csproj: Exe, net10.0, <RuntimeIdentifier>win-x64</RuntimeIdentifier>
  • App\App.csproj: Exe, net10.0, <ProjectReference Include="..\Helper\Helper.csproj" ReferenceOutputAssembly="false" />
  • winapp run . --arch arm64
    • This PR: NETSDK1032, The RuntimeIdentifier platform 'win-x64' and the PlatformTarget 'arm64' must be compatible. The build fails.
    • v0.7.1: builds with -r win-arm64 and prints ok.
• Why it matters: Referencing a helper exe only so it builds first is a common pattern, and it isn't limited to analyzers. The cross-architecture analyzer fallback doesn't apply to a native-architecture run, so nothing catches this.
• Smallest fix: Keep buildOnlyReference = true for the analyzer check, but remove the continue so these projects are evaluated like any other reference. An analyzer project has no RID or dynamic platform resolution, so this only adds one evaluation. Please add a project-arch fixture and a unit-test case for a conflicting RID behind a ReferenceOutputAssembly="false" reference.