[Zach Teutsch (zateutsch)]

What and why

winapp run . -p:Configuration=Release on a .NET project built and ran Debug, with no message unless you added -v. -c defaults to Debug, and that default replaced your -p Configuration. C++ projects already handled this correctly.

Now -p Configuration=<name> picks the configuration for .NET projects too, unless you also type -c. If you type both with different values, winapp stops and tells you to pass only one. This applies to:

• winapp run on a project, a folder, a solution, or a single .cs file
• winapp package on a .csproj or .vcxproj
• winapp unregister on a single .cs file, so it removes the configuration that run registered

When a folder or solution holds several projects, winapp now also uses -p Configuration to decide which one is runnable.

Fixes #1278

Before / after

Same command, winapp run . -p:Configuration=Release, on a new console app.

Before (main): builds bin\Debug

After (this branch): builds bin\Release. Passing a different -c is rejected.

Not tested / risks

• I didn't build a full MSIX with winapp package. I checked that package App.csproj -p:Configuration=Debug builds Debug (the package default is Release), and that a conflicting -c is rejected.
• Commands that passed -c X -p:Configuration=Y with different values used to build X with no message. Now they fail with a clear error. The C++ path already did this.

Checklist

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

Notes for reviewers

The issue suggested a warning when -c and -p Configuration disagree. I made it an error instead, matching the existing C++ behavior, because a warning would still build the configuration you didn't want. The C++-only helper became a shared TryResolveConfiguration used by every mode.

Validation: affected test classes pass (690 run/package/project-run tests, Release build). I also checked each mode above with a published Release CLI: a single project, a folder where the app is runnable only in Release, a single .cs file, package, and --json error output.

[Copilot]

🟢 Approval recommended

No active review issues are reported for the configuration-resolution changes.

No open issues 🎉

What changed in this PR

Fixes #1278 so winapp run . -p:Configuration=Release builds Release instead of silently using Debug for .NET projects. Configuration selection now follows the same rules across .NET and C++ run and package modes.

Changes:

• Shares configuration resolution across project, single-file, and package modes, rejecting conflicting explicit -c and -p Configuration values.
• Uses the resolved configuration when selecting runnable projects from folders or solutions.
• Adds regression tests and updates command help and usage documentation.

File	Description
src/​winapp-CLI/​WinApp.Cli/​Services/​ProjectRunService.cs	Removes the obsolete configuration-override diagnostic.
src/​winapp-CLI/​WinApp.Cli/​Services/​ProjectRunService.Cpp.cs	Removes the C++-specific configuration helper.
src/​winapp-CLI/​WinApp.Cli/​Services/​ProjectRunService.Arguments.cs	Adds shared configuration resolution and conflict detection.
src/​winapp-CLI/​WinApp.Cli/​Commands/​RunCommand.SingleFileMode.cs	Resolves configuration before single-file builds.
src/​winapp-CLI/​WinApp.Cli/​Commands/​RunCommand.ProjectMode.cs	Applies configuration resolution to builds and project selection.
src/​winapp-CLI/​WinApp.Cli/​Commands/​PackageCommand.ProjectMode.cs	Honors configuration properties for .NET packaging.
src/​winapp-CLI/​WinApp.Cli/​Commands/​PackageCommand.cs	Updates property-option help text.
src/​winapp-CLI/​WinApp.Cli/​Commands/​PackageCommand.CppMode.cs	Uses shared resolution for C++ packaging.
src/​winapp-CLI/​WinApp.Cli.Tests/​RunCommandSingleFileModeTests.cs	Tests single-file configuration selection and conflicts.
src/​winapp-CLI/​WinApp.Cli.Tests/​RunCommandProjectModeTests.cs	Tests .NET configuration selection, classification inputs, and conflicts.
src/​winapp-CLI/​WinApp.Cli.Tests/​ProjectRunServiceCppTests.cs	Updates tests to reference the shared helper.
src/​winapp-CLI/​WinApp.Cli.Tests/​PackageCommandProjectModeTests.cs	Tests packaging configuration selection and conflicts.
docs/​usage.md	Documents configuration selection and conflict rules.

_{Review effort: Balanced}

[github-actions]

Build Metrics Report

Validation passed. All required build and validation jobs succeeded.

Binary Sizes

Artifact	Baseline	Current	Delta
CLI (ARM64)	65.45 MB	65.45 MB	📉 -0.5 KB (-0.00%)
CLI (x64)	65.35 MB	65.35 MB	📉 -1.0 KB (-0.00%)
MSIX (ARM64)	27.09 MB	27.09 MB	📉 -0.8 KB (-0.00%)
MSIX (x64)	28.70 MB	28.70 MB	📈 +0.1 KB (+0.00%)
NPM Package	56.42 MB	56.42 MB	📈 +1.5 KB (+0.00%)
NuGet Package	56.57 MB	56.57 MB	📈 +0.2 KB (+0.00%)

.NET Test Results (TRX reports)

Other suites are reflected in the overall validation status above.

✅ 11029 passed, 44 skipped out of 11073 tests in 1783.0s (+10 tests, -335.7s vs. baseline)

Test Coverage

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

CLI Startup Time

76ms 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))) 1282

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 1282

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

---

Updated 2026-11-05 03:43:51 UTC · commit c61bda5 · workflow run

[Chiara Mooney (chiaramooney)]

One feedback point:

Honor the same configuration when unregistering a single-file app

What is wrong: run app.cs -p:Configuration=Release now uses Release, but unregister app.cs -p:Configuration=Release still evaluates Debug. This matters when the app’s package name depends on its configuration.

Show me: Put this in Directory.Build.props beside a packaged app.cs:

XML

<Project>
  <PropertyGroup>
    <WinAppPackageName>Review.Pr1282.7303805d.$(Configuration)</WinAppPackageName>
  </PropertyGroup>
</Project>

Then run:

PowerShell

winapp run app.cs -p:Configuration=Debug --no-launch --without-alias
winapp run app.cs -p:Configuration=Release --no-launch --without-alias
winapp unregister app.cs -p:Configuration=Release --json

The last command returned exit code 0 and removed Debug:

JSON

{
  "Unregistered": [
    "Review.Pr1282.7303805d.Debug_1.0.0.0_arm64__ckwfgjjyn72wr"
  ]
}

Expected: remove Release and leave Debug alone. Release remained registered until I explicitly used unregister app.cs -c Release.

Why it matters: Repeating the run’s configuration property can remove another configuration’s registration and potentially its app data. If Debug isn’t installed, cleanup silently leaves Release installed instead.

Smallest fix: Use TryResolveConfiguration in single-file unregister before constructing SingleFileIdentityInputs, and add a regression test. The cleanup command printed by run already includes -c Release and works.

Location: [RunCommand.SingleFileMode.cs:87–91](

winappCli/src/winapp-CLI/WinApp.Cli/Commands/RunCommand.SingleFileMode.cs

Lines 87 to 91 in 2d2b3ea

	if (!ProjectRunService.TryResolveConfiguration(
	configuration, parseResult.GetResult(ConfigurationOption) is { Implicit: false }, properties,
	out configuration, out var configurationError))
	{
	return Fail(configurationError!, isJson);

), with the missing resolution in [UnregisterCommand.cs:284–288](

winappCli/src/winapp-CLI/WinApp.Cli/Commands/UnregisterCommand.cs

Lines 284 to 288 in 2d2b3ea

	var identityInputs = new SingleFileIdentityInputs(
	configuration ?? "Debug",
	architecture,
	ArchitectureIsExplicit: !string.IsNullOrWhiteSpace(archOption) || !string.IsNullOrWhiteSpace(runtimeOption),
	properties);

).

[Zach Teutsch (zateutsch)]

Fixed in ac3d87e: winapp unregister app.cs -p:Configuration=Release now removes the Release registration, and a conflicting -c is rejected.