Pass open AppHost to CLI commands via --project flag

[adamint]

Description

When CLI commands like deploy, publish, add, and update are invoked from the VS Code extension, they now automatically pass --project <path> to the Aspire CLI if an AppHost is available. The AppHost is resolved with the following priority:

1. Active editor — if the currently open file is an AppHost .cs file (detected by the #:sdk Aspire.AppHost.Sdk marker)
2. Workspace settings — if .aspire/settings.json has a configured appHostPath

Previously, these commands sent bare CLI commands (e.g., aspire deploy) without any project context, requiring the CLI to search the workspace from scratch — even when the user already had the AppHost open.

Commands updated

• deploy — accepts --project via PipelineCommandBase
• publish — accepts --project via PipelineCommandBase
• add — accepts --project via AddCommand
• update — accepts --project via UpdateCommand

Commands NOT changed (by design)

• new / init — create new projects; don't operate on existing AppHosts
• openTerminal, configureLaunchJson, settings, openLocalSettings, openGlobalSettings — configuration/utility commands
• runAppHost / debugAppHost — already used the open AppHost

Changes

• Extracted getAppHostPath() as a public method on AspireEditorCommandProvider (reuses existing resolution logic from tryExecuteRunAppHost)
• Added additionalArgs parameter to sendAspireCommandToAspireTerminal
• Created appHostArgs.ts utility for building --project arguments
• Updated command files and registrations to pass the resolved AppHost

Fixes #11024

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
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
  • No
• Does the change require an update in our Aspire docs?
  • Yes
  • 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/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 14688

Or

• Run remotely in PowerShell:

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

[Copilot]

Pull request overview

This PR updates the VS Code extension’s Aspire CLI command invocations to automatically pass the currently resolved AppHost via --project <path>, prioritizing the active editor AppHost over .aspire/settings.json, so the CLI doesn’t need to re-scan the workspace.

Changes:

• Added an AppHost argument helper (getProjectArgs) for building --project args.
• Extended AspireTerminalProvider.sendAspireCommandToAspireTerminal to accept additional CLI args.
• Updated add, update, deploy, and publish command registrations/implementations to pass resolved AppHost context.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
extension/src/utils/appHostArgs.ts	Adds helper to produce --project args from the resolved AppHost path.
extension/src/utils/AspireTerminalProvider.ts	Allows sending additional args when composing terminal CLI commands.
extension/src/extension.ts	Wires updated commands to pass AspireEditorCommandProvider for AppHost resolution.
extension/src/editor/AspireEditorCommandProvider.ts	Exposes getAppHostPath() and broadens AppHost detection heuristics.
extension/src/commands/add.ts	Passes resolved --project args to aspire add.
extension/src/commands/update.ts	Passes resolved --project args to aspire update.
extension/src/commands/deploy.ts	Passes resolved --project args to aspire deploy.
extension/src/commands/publish.ts	Passes resolved --project args to aspire publish.

[adamint]

@copilot open a new pull request to apply changes based on the comments in this thread