[Nikola Metulev (nmetulev)]

What and why

Visual Studio users often pick the build configuration with -p:Configuration=Release. On a C++ .vcxproj, winapp run ignored that property and used Debug. With --no-build, it then looked for the Debug output instead of the Release build you asked for.

Now -p:Configuration=X on a .vcxproj works like -c X, the same way -p:Platform already picks the architecture. If you pass both -c and -p:Configuration with different values, winapp stops before building and tells you to pass only one. .NET projects don't change.

Fixes #1075

Before / after

The command runs against a stub AppHost.vcxproj that hasn't been built, so both runs end with "executable not found". The header line and the path winapp looks for show the difference.

Before (main): Debug | arm64, looking in ARM64\Debug

After (this branch): Release | arm64, looking in ARM64\Release. Conflicting -c and -p:Configuration values fail with one line.

Not tested / risks

I only tested on a stub .vcxproj, not on a full C++ app build.

Checklist

• Tests added or updated
• Tested locally on Windows
• Docs, samples, and plugins/winapp/skills/ updated if user-facing behavior changed

Notes for reviewers

• Configuration names are compared case-insensitively, so -c release -p:Configuration=Release is allowed.
• Choosing which project to run in a folder or solution doesn't depend on the configuration for C++ projects, so that step didn't need this change.

[Copilot]

🟢 Approval recommended

The implementation matches the issue requirements, and the Release build, targeted tests, and CLI scenarios passed.

0 open findings

What changed in this PR

This PR makes winapp run honor -p:Configuration for C++ projects while preserving .NET behavior.

Changes:

• Resolves C++ configuration from -p Configuration=X.
• Rejects conflicting -c and -p Configuration values.
• Adds tests and updates C++ usage documentation.

File	Description
ProjectRunService.Cpp.cs	Extracts and forwards the effective C++ configuration.
RunCommand.ProjectMode.cs	Applies configuration precedence and conflict validation.
RunCommandProjectModeTests.cs	Tests selection and conflict behavior.
ProjectRunServiceCppTests.cs	Tests property parsing and MSBuild tokens.
docs/​usage.md	Documents C++ configuration selection.

🧠 Review effort: Balanced

---

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

[github-actions]

Build Metrics Report

Validation passed. All required build and validation jobs succeeded.

Binary Sizes

Artifact	Baseline	Current	Delta
CLI (ARM64)	59.54 MB	59.54 MB	📈 +0.5 KB (+0.00%)
CLI (x64)	59.52 MB	59.52 MB	📈 +1.0 KB (+0.00%)
MSIX (ARM64)	24.72 MB	24.72 MB	📈 +0.9 KB (+0.00%)
MSIX (x64)	26.23 MB	26.23 MB	📈 +1.7 KB (+0.01%)
NPM Package	51.57 MB	51.57 MB	📈 +0.5 KB (+0.00%)
NuGet Package	51.68 MB	51.68 MB	📈 +1.0 KB (+0.00%)

.NET Test Results (TRX reports)

Other suites are reflected in the overall validation status above.

✅ 8801 passed, 39 skipped out of 8840 tests in 1695.2s (+5 tests, +11.1s vs. baseline)

Test Coverage

✅ 87.6% line coverage, 82% branch coverage · ✅ no change vs. baseline

CLI Startup Time

59ms median (x64, winapp --version) · 📉 -12ms 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))) 1085

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 1085

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

---

Updated 2026-10-16 00:07:45 UTC · commit 16633a4 · workflow run