Fix VS Code AppHost launch path resolution#17408
Open
davidfowl wants to merge 11 commits into
Open
Conversation
Contributor
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 17408Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 17408" |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes Aspire VS Code extension launch path handling so that when users start an Aspire debug session from an SDK-style C# AppHost source file (typically Program.cs), the extension resolves that source path to the containing AppHost project (.csproj) before invoking the Aspire CLI via --apphost.
Changes:
- Added
resolveAppHostLaunchPathutility to normalize C# AppHost launch paths (Program.cs→ containing project; single-file#:sdk Aspire.AppHost.Sdkstays as source). - Updated
AspireEditorCommandProvider.getAppHostPath()to return the normalized launch path when launching from the active editor. - Updated
AspireDebugConfigurationProvider.resolveDebugConfigurationWithSubstitutedVariables()to normalizelaunch.jsonprogramvalues post-substitution, with unit tests covering key scenarios.
Show a summary per file
| File | Description |
|---|---|
| extension/src/utils/appHostLaunchPath.ts | Introduces the path normalization logic for C# AppHost launches. |
| extension/src/editor/AspireEditorCommandProvider.ts | Uses normalization when launching from the active editor’s AppHost file. |
| extension/src/debugger/AspireDebugConfigurationProvider.ts | Normalizes program after variable substitution for launch configs. |
| extension/src/test/aspireEditorCommandProvider.test.ts | Adds unit tests for active-editor launch path normalization. |
| extension/src/test/aspireDebugConfigurationProvider.test.ts | Adds unit tests for launch configuration normalization behavior. |
Copilot's findings
- Files reviewed: 5/5 changed files
- Comments generated: 1
Contributor
Author
|
Replying to Copilot review overview #17408 (review): thanks for the review. The PR has since been refactored from the original |
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
JamesNK
reviewed
May 24, 2026
Member
JamesNK
left a comment
JamesNK
left a comment
There was a problem hiding this comment.
Reviewed the AppHost discovery refactor. Found 2 issues:\n\n- 1 resource leak/correctness issue: Spawned CLI process in runCliForStdout is never tracked — no timeout, no kill-on-dispose, and a hung process permanently blocks the cached discovery promise for the workspace.\n- 1 performance issue: File system watchers use broad **/*.csproj patterns without excluding build output directories, which can trigger excessive CLI re-invocations during builds in large workspaces.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
Author
|
Replying to review summary #17408 (review): thanks, agreed on both points. I addressed the inline threads in c3c8505 by adding discovery CLI timeout/cancellation on dispose and filtering watcher invalidations for output and vendor directories. |
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
16 tasks
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
|
Re-running the failed jobs in the CI workflow for this pull request because 1 job was identified as retry-safe transient failures in the CI run attempt.
|
Contributor
|
❌ CLI E2E Tests failed — 95 passed, 1 failed, 5 unknown (commit Failed Tests
View all recordings
📹 Recordings uploaded automatically from CI run #26405806207 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This fixes VS Code AppHost launch path handling when users run or debug Aspire from source files instead of project files. Previously, starting an Aspire debug session from an SDK-style C# AppHost source file such as
Program.cscould pass that source path through to the Aspire CLI as--apphost <path>/Program.cs, which the CLI does not accept for SDK-style AppHosts.The extension now uses CLI-backed AppHost discovery as the source of truth for launch targets:
aspire ls --format jsondiscovers AppHost candidates for the workspace.aspire lsalso includes the AppHost configured inaspire.config.json, even when that AppHost lives outside the current working directory's normal discovery results..csprojresolve to that project file before launch.${workspaceFolder}/AppHost/Program.cscan resolve to the discovered AppHost project.User-facing usage
Users can still point an Aspire launch configuration at the AppHost project file:
{ "type": "aspire", "request": "launch", "program": "${workspaceFolder}/AppHost/AppHost.csproj" }If a user starts debugging while an SDK-style AppHost source file is active, or a launch configuration points at that source file, the extension resolves the launch target to the containing discovered AppHost project before invoking the CLI. Single-file AppHosts still launch directly from source:
TypeScript AppHosts discovered by the CLI continue to launch from the source file path:
Fixes # (issue)
Validation
npm run compile-tests -- --pretty falsenpm run unit-test -- --grep "AspireDebugConfigurationProvider"npm run unit-test -- --grep "TypeScript apphost|AspireEditorCommandProvider|AppHost discovery|AspireDebugConfigurationProvider"dotnet test --project tests/Aspire.Cli.Tests/Aspire.Cli.Tests.csproj --no-launch-profile -- --filter-class "*.LsCommandTests" --filter-not-trait "quarantined=true" --filter-not-trait "outerloop=true"cd tests/testproject && aspire ls --format jsonaspire.config.jsonpointing outside the working directory, thendotnet run --project src/Aspire.Cli/Aspire.Cli.csproj -- ls --format jsonverified the configured AppHost is included.aspire init --language typescript --suppress-agent-init --non-interactive, then ranaspire ls --format jsonand verified it returns theapphost.tscandidate withlanguage: "typescript/nodejs".git diff --checkChecklist
<remarks />and<code />elements on your triple slash comments?