Aspnetcore: Invalid launch.json configuration created for hosted Blazor apps

Created on 22 May 2020  路  1Comment  路  Source: dotnet/aspnetcore

Bug Description
The incorrect launch configuration is populated for hosted Blazor apps.

Steps to Reproduce

  1. Create a new hosted Blazor app using dotnet new blazorwasm --hosted -o hosted.
  2. Open the project in VS Code.
  3. When the pop-up to resolve dependencies opens up, confirm.
  4. Note that the launch configuration created assumes a standalone app at ${workspaceFolder}/Server.

Screen Shot 2020-05-22 at 11 04 49 AM

The actual debugging of hosted apps still works if you edit the pre-generated launch configuration to have the right contents.

Done area-razor.tooling bug feature-razor.vscode

Most helpful comment

It appears that this bug has been around for quite a while.

A few days back @NTaylorMullen and I were doing some investigation into a broken launch configuration from a hosted project in an earlier version of Omnisharp. The launch config that was created didn't look correct, it was basically the launch config for a standalone web project but located within a server directory.

Now I realize that the logic within Omnisharp that determines whether a Blazor WASM project is hosted or standalone is a little wonky. It ends up categorizing all hosted projects as standalone projects inside a sub-directory.

This is why in the production version of the Omnisharp extension you get a launch config that assumes you want to run a project under {workspaceFolder}/Server using a standard .NET launch config.

 {
            "name": ".NET Core Launch (Blazor Standalone)",
            "type": "coreclr",
            "request": "launch",
            "program": "dotnet",
            "args": ["run"],
            "cwd": "${workspaceFolder}/HostedDebug/Server",
            "env": {
                "ASPNETCORE_ENVIRONMENT": "Development"
            }
        }
}

In the pre-release version with the new Blazor debug adapter, you get a launch configuration that looks like this:

{
  type: "blazorwasm",
  ....
  cwd: "{workspaceFolder}/Server"
}

To resolve this, and likely other issues that are a result of hosted projects being incorrectly defined, we'll need to design a better heuristic to distinguish between hosted and standalone projects.

>All comments

It appears that this bug has been around for quite a while.

A few days back @NTaylorMullen and I were doing some investigation into a broken launch configuration from a hosted project in an earlier version of Omnisharp. The launch config that was created didn't look correct, it was basically the launch config for a standalone web project but located within a server directory.

Now I realize that the logic within Omnisharp that determines whether a Blazor WASM project is hosted or standalone is a little wonky. It ends up categorizing all hosted projects as standalone projects inside a sub-directory.

This is why in the production version of the Omnisharp extension you get a launch config that assumes you want to run a project under {workspaceFolder}/Server using a standard .NET launch config.

 {
            "name": ".NET Core Launch (Blazor Standalone)",
            "type": "coreclr",
            "request": "launch",
            "program": "dotnet",
            "args": ["run"],
            "cwd": "${workspaceFolder}/HostedDebug/Server",
            "env": {
                "ASPNETCORE_ENVIRONMENT": "Development"
            }
        }
}

In the pre-release version with the new Blazor debug adapter, you get a launch configuration that looks like this:

{
  type: "blazorwasm",
  ....
  cwd: "{workspaceFolder}/Server"
}

To resolve this, and likely other issues that are a result of hosted projects being incorrectly defined, we'll need to design a better heuristic to distinguish between hosted and standalone projects.

Was this page helpful?
0 / 5 - 0 ratings