-
Notifications
You must be signed in to change notification settings - Fork 760
Fix: issues with extension support for project resources (do not run resources inheriting from ProjectResource in IDE if they do not have SupportsDebuggingAnnotation, fix case where some project resources would not be run in IDE, wrong capability id) #12939
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Fix: issues with extension support for project resources (do not run resources inheriting from ProjectResource in IDE if they do not have SupportsDebuggingAnnotation, fix case where some project resources would not be run in IDE, wrong capability id) #12939
Conversation
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 12939Or
iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 12939" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR fixes three related issues with extension support for project resources:
- Critical bug fix: Resources inheriting from
ProjectResourcewithoutSupportsDebuggingAnnotationwere incorrectly being launched via IDE, causing issues like missing console output in Functions apps - Missing annotation: The generic
AddProject<TProject>overload withAction<ProjectResourceOptions>was missing the requiredWithDebugSupportcall - Incorrect capability ID: Updated from "ms-dotnettools.csharp" to "project" in three locations
Key Changes
- Added annotation check in
DcpExecutor.PrepareProjectExecutables()to only use IDE execution mode for projects withSupportsDebuggingAnnotation - Added
WithDebugSupportcall to the genericAddProject<TProject>overload to ensure all project resources get debugging support - Updated capability IDs from "ms-dotnettools.csharp" to "project" for consistency
Reviewed Changes
Copilot reviewed 4 out of 5 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| src/Aspire.Hosting/Dcp/DcpExecutor.cs | Added check for SupportsDebuggingAnnotation before using IDE execution type |
| src/Aspire.Hosting/ProjectResourceBuilderExtensions.cs | Added missing WithDebugSupport call and corrected capability IDs to "project" |
| src/Aspire.Hosting/SupportsDebuggingAnnotation.cs | Minor whitespace cleanup |
| tests/Aspire.Hosting.Tests/ProjectResourceTests.cs | Added tests verifying all project builder methods add SupportsDebuggingAnnotation |
| tests/Aspire.Hosting.Tests/Dcp/DcpExecutorTests.cs | Added test verifying projects without annotation run in Process mode |
| && !string.IsNullOrEmpty(_configuration[DebugSessionPortVar]) | ||
| && supportedLaunchConfigurations is not null | ||
| && supportedLaunchConfigurations.Contains(supportsDebuggingAnnotation.LaunchConfigurationType)) | ||
| if (executable.SupportsDebugging(_configuration, out var supportsDebuggingAnnotation)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there were like 3 implementations of this logic, it is all now encapsulated in ExtensionUtils.SupportsDebugging and accurately tested. eliminates a possible source of bugs
|
Unrelated bu I am curious what it would take to do on demand debugging via a command. |
I've been gaming this scenario out. We can model the debugger as a child resource that does not start automatically, as unlike with a command, you only need to attach once. |
|
Why would it need to be a child resource? |
A debugger has two clear states: attached and not attached, which can map to running and waiting. You can also show the (perhaps complicated) details in the details panel . You also realistically only have one debugger attached to a given resource at a time**. And, a resource that automatically starts is an advantage over commands in scenarios like browser debugging, where you may want to automatically spin up a debug instance of chrome/edge/firefox. It's late so that's written poorly, sorry. The idea is that you would only need to create a new resource, call this updated WithDebugSupport method that offers you the freedom to set whatever debugger properties you want in the |
Description
A lack of check for the presence of
SupportsDebuggingAnnotationmeant that children ofProjectResourcewere being launched via IDE. This bug also affects dev kit, where functions apps are successfully launched via the IDE but with no console output. The fix is to only run a project executable in IDE execution mode if it contains that annotation.In addition, one
AddProjectoverload did not have the requiredWithDebugSupportcall, meaning it needs to be added so that all project resources still continue to be run via the IDE.Lastly, I did not update the debug support capability for project resources from the c# extension id to project. This has no effective implications for the extension, but is incorrect.
To test, you can run the functions playground app, an app containing a python resource (such as python), and any other app that contains project resources. I have tested both command-line run and through the VS Code extension to confirm that this fix works.
Needs backport.
Checklist
<remarks />and<code />elements on your triple slash comments?doc-ideatemplatebreaking-changetemplatediagnostictemplate