Polyglot debugging support

[tjwald]

As part of the 2025-2026 roadmap, there is a section on polyglot debugging.
@davidfowl mentioned that this is already supported in Aspire just not out of the box, and when I reached out to Jetbrains Rider they said that they are blocked.
Please discuss - we really want this polyglot debugging support as we are using dotnet, typescript, go and python.

[davidfowl]

cc @adamint

[rafaelldi]

Hi, folks! As I understand it, DCP only calls the IDE for dotnet projects. Support for other languages is implemented in the form of executables (as far as I know). And IDEs are not involved in this flow.

[rafaelldi]

Thanks! I will discuss that with my colleagues and return to you shortly

[rafaelldi]

So, we've discussed and have a few questions about it:

1. In your plan, should the debugger interface remain in the IDE, or will the entire interface be only in the Aspire dashboard? I see two options here: the first is that the entire debug session looks the same to a user, but IDE reacts not only to user actions, but also to DAP requests at the same time (for example, it will be the same if the user pressed the step-in button or we received such a request from Aspire). The second option is that we only provide our DAP-compatible debugger worker (a separate "backend" process) without any UI. In this case, it will be controlled only by Aspire (as far as I understand, from the dashboard). We could support both cases; the question is what would be preferred, according to the new approach.
2. What do you plan to do with breakpoints? If we act as a DAP debugger, we should receive breakpoints from Aspire (correct me if I'm wrong). But how will the user set breakpoints in the Aspire dashboard? Are you planning to add a file view? Or will breakpoints be set in the IDE, and then this information will be sent to Aspire and back to the debugger?
3. What about run? Right now, Aspire requests the IDE also to run some applications (not only debug). Will Aspire now run applications on its own?

In general, it is entirely possible for us to support the DAP protocol, but as always, the devil is in the details.

[danegsta]

I expect that any UI we build around debugging in the dashboard would be limited and primarily informational; when we’re running in an IDE the user already has access to a much better debugging UI/UX than we’d want to integrate into the dashboard. We night update resource status to reflect that it’s suspended at a breakpoint, for example, but we don’t want to add a code view or UI for step through debugging controls as that’s exactly what their IDE is built to provide.

The one scenario where I do expect us to issue debugger commands at the same time as the IDE would be in an agentic mode, where a user asks a coding agent to debug an Aspire service and via MCP tools it would programmatically set breakpoints, interact with the application, check state when suspended, step through, all that. That’s obviously going to require us to reconcile the state as declared by the IDE and any agent driven actions and send DAP events such as Breakpoint to reflect any changes back to the IDE.

We want to have run use this new flow as well as we want to make sure the IDE still has information about what services are running whether running with debugging or not as that’s obviously valuable for building good developer experiences. The goal is to enable new features with this approach, but not at the expense of existing developer experiences.

[danegsta]

TLDR: this change is intended to support additional programmatic scenarios and standardize adding additional language debug support, not replace any parts of the IDE debugger UI.

[rafaelldi]

Thank you for the answers!

[runxc1]

Landed here as I was trying to get polyglot debugging working with a couple of nextjs projects that call into all of my dotnet apis that are already using Aspire. Is this only currently supported for Python?

[tjwald]

Only supports python via vscode extension. Node comming soon.
This discussion is for jetbrains that doesn't support the python debugging yet.