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)

[adamint]

Description

A lack of check for the presence of SupportsDebuggingAnnotation meant that children of ProjectResource were 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 AddProject overload did not have the required WithDebugSupport call, 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

• Is this feature complete?
  • [X] Yes. Ready to ship.
  • [ ] No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • [X] 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
  • [X] 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
  • [X] No
• Does the change require an update in our Aspire docs?
  • [ ] Yes
    • Link to aspire-docs issue (consider using one of the following templates):
      • New (or update) doc-idea template
      • New breaking-change template
      • New diagnostic template
  • [X] No

[github-actions[bot]]

🚀 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 -- 12939

Or

• Run remotely in PowerShell:

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

[davidfowl]

Unrelated bu I am curious what it would take to do on demand debugging via a command.

[adamint]

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.

[davidfowl]

Why would it need to be a child resource?

[adamint]

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 launchConfigurationProducer by using a launch configuration class that inherits from ExecutableLaunchConfigurationWithDebuggerProperties. That's how I implemented a JS frontend debugger resource.