Provide VS Code launch.json or other instructions to successfully get debuging working against the host project.

[JohnGalt1717]

This is what is created automatically:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "C#: AspireDebug",
            "type": "dotnet",
            "request": "launch",
            "projectPath": "${workspaceFolder}/Host/Host.csproj"
        }
    ]
}

It doesn't work with an error that it doesn't support debugging.

I do have a live license for the C# Dev stuff and it's working as far as that goes.

If I right click on the project in the solution and choose debug I get: Failed to configure dashboard resource because ASPNETCORE_URLS environment variable was not set.

If I just hit F5 per the instructions I get the same error.

If I run it with coreclr in the launch.json it will run and debug but it doesn't pick up the token.

        {
            "name": "Debug AspireApi",
            "type": "coreclr",
            "request": "launch",
            "program": "${workspaceFolder}/Host/bin/Debug/net8.0/Host.dll",
            "preLaunchTask": "Solution: Build",
            "env": {
                "ASPNETCORE_ENVIRONMENT": "Development",
                "DOTNET_ENVIRONMENT": "Development",
                "DOTNET_DASHBOARD_OTLP_ENDPOINT_URL": "https://localhost:21212",
                "DOTNET_RESOURCE_SERVICE_ENDPOINT_URL": "https://localhost:22212",
                "ASPNETCORE_URLS": "https://localhost:18210",
                "ASPIRE_ALLOW_UNSECURED_TRANSPORT": "true"
            },
            "launchBrowser": {
                "enabled": true
            },
        },

Hence either none of this is actually working per the claim, or there is magic configuration that needs to happen which is not documented.

Please advise.

[davidfowl]

What version of the DevKit are you using? I made a video last night of the experience and debugging works out of the box. You need to use the preview version though.

I should add, can you try this on a new preview 6 aspire project? I'd like to make sure this isn't a migration from an earlier preview problem.

[JohnGalt1717]

So I switched to the preview of the C# DevKit and with this:

        {
            "name": "Debug Aspire Api",
            "type": "dotnet",
            "request": "launch",
            "projectPath": "${workspaceFolder}/Host/Host.csproj",
        },

But I still get:

'd:/Repos/test/api/Host/Host.csproj' does not support debugging. No launchable target found.

[davidfowl]

Can you attempt the same on a new project? Just to make it it works elsewhere?

[JohnGalt1717]

IF there is no launch.json it works with whatever magic there is. But there doesn't appear to be a way to translate that magic into a launch.json and if I try the above same launch.json, it fails with the same error.

Also, I just noticed that the error happens even with the magic no launch.json but it starts and works anyhow.

So just need a working launch.json... (and those magic debugger things really need VS code to have someway of saying "yup that worked, make it into a launch.json for me")

[davidfowl]

cc @kvenkatrajan

[kvenkatrajan]

launch.json is currently not supported for Aspire launching- C# dev kit uses the in memory launch provider and displays a list of launchable targets which when selected would launch/debug the apphost. @WardenGnaw to confirm.

That being said, a version of C# dev kit compatible with the preview6 Aspire is in works. Once it gets released to prerelease, we will update this ticket.

[JohnGalt1717]

launch.json is currently not supported for Aspire launching- C# dev kit uses the in memory launch provider and displays a list of launchable targets which when selected would launch/debug the apphost. @WardenGnaw to confirm.

That being said, a version of C# dev kit compatible with the preview6 Aspire is in works. Once it gets released to prerelease, we will update this ticket.

Thanks! It's pretty important to get this working with launch.json because of instance, I have launches that do things like run migrations, etc. that I need in there so being all or nothing is a large blocker for most projects of any significant size.

[kvenkatrajan]

I have launches that do things like run migrations, etc.

What kinds of migration - can you provide examples of your launch.json file please? Can this be achieved by using launchsettings.json?

CC: @tmeschter, @WardenGnaw, @webreidi

[JohnGalt1717]

EF Core migrations. We provide debug for devs to run the pre-job for k8s that executes the migration, and then if successful continues the rollout of the deployment.

We also have several other jobs that run as crons on K8s that need to be debugged outside of aspire that are in there.

So we definitely have to have a launch.json for aspire host that debugs too.

Ideally it would also give us access to every project that the aspire host depends upon and let us restart those separately so that we can make changes to a given project and not have to rerun the entire aspire host launch while maintaining the host, and continuing debug after the restart. (yes hot restart handles some of this, but there are more cases where hot restart doesn't work than cases where it does. This is also a serious inner loop issue in VS.net, and while Rider could do it, it doesn't work with Aspire.)

[WardenGnaw]

@JohnGalt1717 You can save the launch.json configuration used by the in-memory experience if you use F5 -> Select the C# Debugger -> and hit the gear icon from one of the launch selections.

This will add a configuration to your launch.json.

{
   "name": "C#: AspireDemoProject.AppHost [Default Configuration]",
   "type": "dotnet",
   "request": "launch",
   "projectPath": "${workspaceFolder}\\AspireDemoProject.AppHost\\AspireDemoProject.AppHost.csproj"
}

there you can use existing VS Code debug configuration options, however it does not have the coreclr debug options.

You can also handwrite a dotnet configuration type and a path to the project via projectPath

[JohnGalt1717]

I've done so. It creates a generic template, not what it actually used to run it.

And it also doesn't work. I've tried the exact code you've given using the latest preview of the plugin and it still throws the error described. (also really bad UX)

[dahermansson]

@JohnGalt1717 Can you try the automatically created launch.json

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "C#: AspireDebug",
            "type": "dotnet",
            "request": "launch",
            "projectPath": "${workspaceFolder}/Host/Host.csproj"
        }
    ]
}

with replacing the slash (/) with double backslash (\\) i projectPath and see if that makes it work?

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "C#: AspireDebug",
            "type": "dotnet",
            "request": "launch",
            "projectPath": "${workspaceFolder}\\Host\\Host.csproj"
        }
    ]
}

Thats seams to fix the "does not support debugging. No launchable target found." at least.

[JohnGalt1717]

It does. Thank you.

Is there any option to be able to specify which browser and the command line args for that browser to use?

[SheepReaper]

Possible workaround:

• (assuming no launch.json or tasks.json) use the .NET: Generate Assets for Build and Debug command
• Target the apphost project
• debug the apphost project
• start a new debugging session using the attach configuration, targeting the sub project you want (search the list by project name) I didn't even know vscode supported multiple debugging sessions

granted, this completely bypasses the dotnet (project) launch type, but it doesn't work so gotta go with what works. and ofc watching for changes is out of the question. Not sure what the path forward here is.