Handle required architecture publish profiles in winapp run

[Nikola Metulev (nmetulev)]

Description

Fixes winapp run --arch for project graphs where the app chooses a publish profile through $(Platform), the effective configuration enables trimming without self-containment, and forcing a global MSBuild Platform would be unsafe for an AnyCPU project reference.

The command now:

• preserves the existing RID-only and guarded Platform paths by default
• evaluates PublishTrimmed, PublishAot, and SelfContained before building
• selects an existing architecture-matching, self-contained publish profile only when required
• rejects ambiguous profiles and profiles that could propagate into a referenced project
• keeps restore, build, property evaluation, and --no-build output discovery aligned

Usage Example

winapp run .\App.csproj -c Release --arch arm64

No additional property is required when the project already declares matching architecture publish profiles.

Related Issue

N/A

Type of Change

• 🐛 Bug fix
• 📝 Documentation
• 🧪 Test update

Checklist

• New tests added for new functionality
• Tested locally on Windows
• Language-specific guide updated
• Shipped skill updated

Screenshots / Demo

N/A

Additional Notes

• Project-run regression suite: 200 passed
• CLI, generated schema, npm wrapper, npm package, and NuGet package built successfully
• Revalidated packaged and unpackaged, single- and multi-project, RID-only and guarded-Platform paths against public WinUI projects

[github-actions]

Build Metrics Report

Binary Sizes

Artifact	Baseline	Current	Delta
CLI (ARM64)	43.75 MB	43.77 MB	📈 +23.5 KB (+0.05%)
CLI (x64)	43.74 MB	43.76 MB	📈 +22.5 KB (+0.05%)
MSIX (ARM64)	18.11 MB	18.11 MB	📈 +2.7 KB (+0.01%)
MSIX (x64)	19.21 MB	19.21 MB	📈 +4.5 KB (+0.02%)
NPM Package	37.69 MB	37.71 MB	📈 +24.3 KB (+0.06%)
NuGet Package	37.82 MB	37.83 MB	📈 +19.1 KB (+0.05%)

Test Results

✅ 4815 passed, 5 skipped out of 4820 tests in 778.7s (+29 tests, -24.4s vs. baseline)

Test Coverage

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

CLI Startup Time

61ms median (x64, winapp --version) · ✅ no change 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))) 788

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 788

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

---

Updated 2026-09-09 04:43:56 UTC · commit bee81c7 · workflow run

[Copilot]

Pull request overview

Adds architecture-aware publish-profile inference to winapp run, keeping project-reference builds aligned across restore, build, and output evaluation.

Changes:

• Resolves safe, self-contained architecture profiles for trimmed builds.
• Propagates inferred profiles across build stages and solution restore handling.
• Adds regression tests and updates CLI documentation/generated surfaces.

Reviewed changes

Copilot reviewed 14 out of 14 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/winapp-npm/src/winapp-commands.ts	Updates generated npm API descriptions.
src/winapp-CLI/WinApp.Cli/Services/ProjectRunService.PublishProfile.cs	Implements profile discovery and validation.
src/winapp-CLI/WinApp.Cli/Services/ProjectRunService.cs	Integrates resolution and fallback behavior.
src/winapp-CLI/WinApp.Cli/Services/ProjectRunService.Arguments.cs	Forwards profiles across MSBuild passes.
src/winapp-CLI/WinApp.Cli/Models/ProjectRunModels.cs	Adds the resolved profile option.
src/winapp-CLI/WinApp.Cli/Helpers/RunArchHelper.cs	Updates architecture documentation.
src/winapp-CLI/WinApp.Cli/Commands/RunCommand.cs	Updates option help text.
src/winapp-CLI/WinApp.Cli.Tests/ProjectRunServicePublishProfileTests.cs	Adds profile-selection regression tests.
plugins/winapp/skills/winapp-setup/SKILL.md	Documents profile-aware project runs.
plugins/winapp/com.github.copilot/agents/winapp.agent.md	Updates agent command guidance.
docs/usage.md	Updates the canonical run reference.
docs/npm-usage.md	Updates npm API documentation.
docs/guides/dotnet.md	Explains multi-project profile handling.
docs/cli-schema.json	Regenerates CLI option descriptions.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Zach Teutsch (zateutsch)]

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

PR Review — nmetulev-investigate-run-architecture vs main

Decision

Changes required — inferred publish profiles can silently change the app’s target framework. The published CLI reproduced this with a normal stale Visual Studio profile.

Must fix

Selected publish profile can silently retarget the app

• What is wrong: The fallback accepts a profile after checking only architecture and SelfContained. Because -p:PublishProfile imports every property in the .pubxml, a stale <TargetFramework> overrides the project’s current target framework.
• Show me: Project declares net10.0-windows10.0.26100.0; win-x64.pubxml declares net10.0-windows10.0.19041.0; run winapp run App.csproj -c Release --arch x64 --no-launch -> succeeds and registers output from bin\Release\net10.0-windows10.0.19041.0\win-x64; expected: build the project’s declared net10.0-windows10.0.26100.0 target, or reject the inferred profile.
• Why it matters: winapp run can launch a different app build than Visual Studio or plain dotnet build, potentially removing APIs or changing package behavior without warning.
• Smallest fix: Before accepting an inferred profile, compare its effective TargetFramework with the project’s effective target framework and skip the profile if it would change it. Add this stale-profile case to the existing fallback tests.
• Location: src/winapp-CLI/WinApp.Cli/Services/ProjectRunService.PublishProfile.cs:105-119

Non-blocking

Imported and conditional profile declarations bypass normal MSBuild evaluation

• What is wrong: Discovery reads literal project XML, so it misses PublishProfile from Directory.Build.props and considers declarations whose MSBuild Condition is false.
• Show me: Put <PublishProfile>win-$(Platform).pubxml</PublishProfile> in Directory.Build.props, then run a trimmed framework-dependent app with --arch arm64 -> no profile is inferred and the build still fails with NETSDK1102; expected: the same automatic selection promised for an inline declaration.
• Why it matters: Projects that centralize ordinary MSBuild settings do not receive the new behavior. This is bounded because they fail as they did before this branch.
• Smallest fix: Resolve the declaration with a read-only MSBuild property evaluation using the requested configuration and architecture, rather than interpreting project XML directly.
• Location: src/winapp-CLI/WinApp.Cli/Services/ProjectRunService.PublishProfile.cs:130-155

What was exercised

• .\scripts\build-cli.ps1 — NativeAOT x64/arm64 publish and the C# solution build succeeded; the overall run later failed on unrelated machine/baseline conditions, including stale ARM64 npm command generation, unavailable external NuGet endpoints, Authenticode trust, and cross-architecture dump analysis.
• dotnet run --project .\src\winapp-CLI\WinApp.Cli.Tests\WinApp.Cli.Tests.csproj -c Debug --no-build -- --filter "FullyQualifiedName~ProjectRunServicePublishProfileTests" — all 12 targeted tests passed.
• Published artifacts\cli\win-arm64\winapp.exe run ... -c Release --arch x64 --no-launch --verbose against a throwaway WinUI app — reproduced the silent target-framework switch and successful loose-layout registration.
• MSBuild property-injection red-team attempt using a comma-bearing inferred profile and harmless marker target — the marker did not execute, so the proposed security finding was dropped.
• Not exercised: imported/conditional profile resolution through a complete runtime fixture — it remains non-blocking and static-only; it does not affect the changes-required decision.

[Zach Teutsch (zateutsch)]

Review above, one blocking issue.

The non-blocking issue looks like it might be worth resolving as well to me, but not sure if thats a common case.

[Alexandre Zollinger Chohfi (azchohfi)]

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

Decision

Merge. I built the CLI and reproduced the failure this fixes: a trimmed WinUI app with an AnyCPU project reference fails dotnet build with NETSDK1102, and injecting the architecture-matching publish profile makes it build. Every failure path in the new inference degrades to the previous behavior, and the injected -p:PublishProfile=… shows up in the echoed build command at default verbosity, so the change is visible without --verbose.

Two non-blocking items below. Neither affects behavior.

---

The .NET guide dropped the error users actually search for

What is wrong: The rewritten "Multi-project apps" paragraph replaces the observable symptom with internal vocabulary — "RID-only", "when the effective configuration requires a self-contained profile". RID-only appears nowhere else in docs/ and is never defined, so a reader can't tell what it's contrasting with.

Show me:

• Before: "…referencing an AnyCPU/netstandard2.0 library doesn't fail with CS0006 "metadata file could not be found"."
• After: "…winapp keeps AnyCPU/netstandard2.0 references on their compatible platform… RID-only remains the default; when the effective configuration requires a self-contained profile…"

The searchable error code is gone.

Why it matters: A user hits CS0006, searches the guide, and no longer finds it. AGENTS.md → Audience contracts asks user docs to describe observable behavior rather than implementation machinery.

Smallest fix: Keep the CS0006 sentence and append only what the user needs, e.g. "For a trimmed Release build, winapp picks the architecture-matching publish profile automatically; no extra flags needed."

Location: docs/guides/dotnet.md:209

---

Nothing automated guards the SDK behavior this depends on

What is wrong: The 19 new tests drive the pipeline through FakeDotNetService with canned --getProperty JSON. They cover the inference logic well, but nothing builds a real project, so the external SDK contract the feature exists for is never exercised.

Show me: I confirmed by hand that the contract holds today — a trimmed, framework-dependent WinUI build fails NETSDK1102, and the injected profile fixes it. If a future SDK changes when publish profiles get imported, or when NETSDK1102 fires, every test still passes while the feature silently stops working (or starts firing when it shouldn't).

Why it matters: The trigger is entirely SDK-behavior-dependent, and this is exactly the boundary samples/<name>/test.Tests.ps1 exists to guard.

Smallest fix: samples/winui-app is close already — it declares <PublishProfile>win-$(Platform).pubxml</PublishProfile>. Adding PublishTrimmed plus a stock Properties/PublishProfiles/win-x64.pubxml and asserting the build succeeds would pin it. No new matrix entry needed.

Location: src/winapp-CLI/WinApp.Cli.Tests/ProjectRunServicePublishProfileTests.cs

---

What was exercised

• Published the CLI and ran the produced winapp.exe directly (not dotnet run).
• samples/winui-app + PublishTrimmed + a stock win-x64.pubxml + an AnyCPU netstandard2.0 project reference: baseline dotnet build -c Debug -r win-x64 fails NETSDK1102; winapp run --arch x64 injects -p:PublishProfile=win-x64.pubxml and succeeds.
• Argument-injection attempt: a profile file named win-x64 -o pwned.pubxml was emitted as a single quoted token and no pwned directory was created. (: is illegal in Windows filenames, so -p:-style names can't exist at all.)
• 19/19 ~PublishProfile unit tests pass; solution builds clean.

Not exercised, so treat these as reasoned rather than proven:

• The --no-build evaluate fallback rewrite. CanInferPublishProfile requires Platform to be empty and the new fallback entry only appears when Platform is set, so an inferred profile can never reach a fallback combination — but I did not run it.
• ARM64. Only x64 was exercised.

[Nikola Metulev (nmetulev)]

Addressed the latest feedback from Zach Teutsch (@zateutsch) and Alexandre Zollinger Chohfi (@azchohfi).

• Inferred profiles are now accepted only when their MSBuild-evaluated TargetFramework matches the project’s effective target framework, so a stale .pubxml cannot silently retarget the app.
• Removed the inline-declaration eligibility gate. Imported and conditional profile values are resolved through MSBuild under the effective configuration and requested platform.
• Added unit coverage for stale target frameworks and imported declarations.
• Extended samples/winui-app/test.Tests.ps1 with a real SDK-boundary fixture: a trimmed app, imported Debug/Release profile selectors, and an implicit-AnyCPU netstandard2.0 reference. It proves the RID-only build fails with NETSDK1102, then verifies winapp run selects only the active architecture profile and registers the packaged app.

Validation: 208 project-run tests passed; the winui-app Pester sample passed 4/4; the merged repository build and package generation completed successfully.

[Nikola Metulev (nmetulev)]

Addressed the latest feedback from Zach Teutsch (@zateutsch) and Alexandre Zollinger Chohfi (@azchohfi) in 8d1e5b8.

• Stale target framework: inferred profiles are now rejected unless the profile-imported MSBuild evaluation preserves the project’s effective TargetFramework. Added a regression test for a profile that attempts to change net10.0-windows10.0.26100.0 to net10.0-windows10.0.19041.0.
• Imported/conditional profiles: removed the inline-project declaration gate. MSBuild now resolves profile selectors from imports and conditions under the effective configuration and requested platform. Added imported and conditional unit coverage.
• Real SDK boundary: extended samples/winui-app/test.Tests.ps1 with a temporary trimmed app, imported Debug/Release selectors, and an implicit-AnyCPU netstandard2.0 reference. It proves RID-only dotnet build fails with NETSDK1102, then verifies winapp run selects only the active architecture profile and registers the packaged app.

Validation is green: 208 focused project-run tests, the local winui-app Pester test, the repository build/package flow, and the complete PR CI matrix (including winui-app).

[Copilot]

🟡 Changes recommended

Profile propagation checks miss imported and custom-root references, while packaged-option preflight can reject an app before its required profile is resolved.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 16/16 changed files
• Comments generated: 3
• Review effort level: Balanced

[Zach Teutsch (zateutsch)]

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

Decision

Changes required — the publish-profile inference works and is well-tested, but (1) it silently switches a class of builds that would have succeeded RID-only, and (2) the new comma-as-separator handling isn't mirrored in secret redaction, so a user secret can leak into logs. Everything else (CLI UX, docs/schema/npm sync, structure, scope) came back clean.

Must fix

Secret in a comma-packed MSBuild property is printed unredacted

• What is wrong: This PR taught EscapeMsBuildPropertyValue that , separates MSBuild properties (it now escapes commas), but the sibling secret-redaction and dedicated-switch parsers still split only on ;. A secret packed after a comma slips through unmasked.
• Show me: winapp run . -p Config=Release,SigningPassword=s3cr3t --verbose → MSBuild parses that as two properties, but RedactPropertySegments splits the token only on ;, sees the segment name Config, and echoes SigningPassword=s3cr3t verbatim in the displayed dotnet … command. Expected: the password is redacted.
• Why it matters: Build/signing credentials passed as MSBuild properties leak into terminal and CI logs.
• Smallest fix: Split on both ; and , in RedactPropertySegments (line 461) and the dedicated-switch splitter (line 345) — literal commas already require %2C, so this is safe.
• Location: src/winapp-CLI/WinApp.Cli/Services/ProjectRunService.Arguments.cs:345,461

Inference switches valid framework-dependent trimmed builds onto a self-contained profile

• What is wrong: RequiresSelfContainedProfile treats PublishTrimmed=true && !SelfContained && !PublishAot as proof the build needs a profile. That premise ("the SDK rejects this combo") is a publish constraint; winapp run does a build, and dotnet build -r win-x64 succeeds framework-dependent with PublishTrimmed=true. So a trimmed framework-dependent project that merely has an arch-templated .pubxml gets silently switched to a self-contained build.
• Show me: A trimmed framework-dependent app with Properties\PublishProfiles\win-arm64.pubxml (SelfContained) → winapp run . --arch arm64 injects -p:PublishProfile=win-arm64.pubxml and builds self-contained instead of the framework-dependent output the user configured. The test TrimmedFrameworkDependentBuild_SelectsProfileBeforeBuild asserts this switch happens.
• Why it matters: Deployment mode, restore graph, and output contents change without the user asking — the kind of false confidence that's worse than failing loudly.
• Smallest fix: Narrow the trigger so it only fires when the RID-only build actually fails, and require the candidate profile to preserve the user's intent — including PublishTrimmed=true in candidateProperties, which today's guards never check (a profile that sets PublishTrimmed=false would pass and silently disable trimming). Since a test locks in the current behavior, confirm the switch is intended before changing it.
• Location: src/winapp-CLI/WinApp.Cli/Services/ProjectRunService.PublishProfile.cs:184-187 (RequiresSelfContainedProfile), :139-171 (candidate validation)

Non-blocking

None.

What was exercised

• dotnet build WinApp.Cli.csproj -c Debug — succeeded, 0 warnings, 0 errors.
• The targeted project-run and publish-profile unit tests pass.
• The two root behaviors were reproduced directly: MSBuild parsing -p:Foo=1,Secret=… as two properties, and dotnet build -r win-x64 succeeding framework-dependent with PublishTrimmed=true.
• Not exercised: end-to-end winapp run against a real trimmed WinUI app on a cold NuGet cache (this machine can't reach api.nuget.org). Both findings are grounded in the diff, the branch's own tests, and the MSBuild reproduction.

[Zach Teutsch (zateutsch)]

Few more findings attached above.

[Nikola Metulev (nmetulev)]

Addressed in afeb3fd.

• MSBuild property input now rejects both comma- and semicolon-packed values before build/logging, without echoing values that may contain secrets. -p remains repeatable, with %2C/%3B documented for literal separators. The service-side property lookup, dedicated-switch filtering, warnings, and display redaction also share separator-aware handling as defense in depth.
• Automatic self-contained profile selection is now limited to evaluated EnableMsixTooling=true builds. A real WinUI SDK probe confirmed the trimmed framework-dependent build fails with NETSDK1102 when MSIX tooling is active and succeeds when it is disabled. Candidate profiles must also preserve PublishTrimmed=true.

I kept inference before the build rather than deliberately failing and rebuilding, so restore/build/output evaluation remain one consistent pass. Added regression coverage for the valid framework-dependent case, profiles that disable trimming, packed explicit selectors/frameworks, and secret redaction.