Fix aspire run hang when defaultWatchEnabled and build fails

[Bertolossi]

Description

Fixes a hang in aspire run when the defaultWatchEnabled feature flag is set and the AppHost has a build error.

Repro: With the following in .aspire/settings.json:

"features": {
  "defaultWatchEnabled": true
}

introduce any compile error in the solution and run aspire run. The CLI hangs indefinitely at "Connecting to apphost..." and must be killed manually.

Root cause: In DotNetAppHostProject.RunAsync, the CLI's pre-build step was gated on !watch. In watch mode the CLI delegated building entirely to dotnet watch, which by design does not exit on a build error — it idles waiting for a file change. The CLI then sits on BackchannelCompletionSource forever because the AppHost never starts.

Fix: Drop the !watch condition so the CLI always performs an explicit pre-build (when shouldBuildInCli). On failure, the existing path sets OutputCollector, signals BuildCompletionSource(false), and returns ExitCodeConstants.FailedToBuildArtifacts, so build errors are surfaced to the user and the process exits cleanly. After a successful pre-build, watch mode still passes noBuild: false to dotnet watch run so it can manage its own incremental builds and hot reload.

A regression test (RunCommand_WhenDefaultWatchEnabledFeatureFlagIsTrueAndBuildFails_ReturnsBuildFailure) was added in RunCommandTests to lock the behavior in.

No new dependencies.

Fixes #13142

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Link to aspire.dev issue:
      • New issue
  • No

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 16702

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 16702"

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR ensures the run command exits with a build-failure code (and does not start the AppHost) when default watch mode is enabled and the initial build fails.

Changes:

• Added a regression test asserting build failures in default watch mode return FailedToBuildArtifacts and do not invoke AppHost run.
• Changed AppHost project execution to perform the initial build even when watch mode is enabled.
• Updated inline comments describing noBuild behavior for watch vs non-watch runs.

Reviewed changes

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

File	Description
tests/Aspire.Cli.Tests/Commands/RunCommandTests.cs	Adds coverage for watch-default behavior when the initial build fails.
src/Aspire.Cli/Projects/DotNetAppHostProject.cs	Builds even in watch mode to fail fast before starting AppHost; updates comments around noBuild.

[Bertolossi]

@microsoft-github-policy-service agree