Blazor WASM browser debugging resolves unrelated first workspace executable as managed debugger program

Start with createManagedDebugConfigurationOnBrowser and trace how the browser request's projectPath reaches AssetGenerator.getAssetsPathAndProgram in src/shared/assets.ts; also read src/shared/workspaceConfigurationProvider.ts and src/shared/configurationProvider.ts. Check the existing tests for browser WebAssembly configuration resolution and add coverage showing the requested Blazor project determines the program and assets in a multi-project workspace. Done when the resolved debugger configuration uses that project rather than the first unrelated executable.

Summary

Starting Blazor WebAssembly browser debugging from an Aspire dashboard can fail with a missing-program error for an unrelated executable in the same workspace.

Aspire supplies the correct Blazor client projectPath and URL, but the generated monovsdbg_wasm session does not retain that project path. The C# workspace configuration provider then obtains the managed debugger's program from the first executable project in the workspace.

In the observed workspace, the error names a temporary DLL for an unrelated file-based C# migration script. The user did not intentionally select that script for this debugging operation.

Environment

• Windows x64
• VS Code 1.141.0
• C# extension 11.2.14
• C# Dev Kit 11.3.30
• Aspire VS Code extension 1.24.0
• Aspire AppHost SDK 13.6.1
• Blazor projects target net11.0
• A multi-project solution is configured using dotnet.defaultSolution.

Observed steps

1. Open a multi-project workspace containing an Aspire AppHost, a Blazor Web App/client, and an unrelated runnable file-based C# script.
2. Start the AppHost through VS Code and start the Blazor web resource.
3. Select Debug in Browser for the Blazor resource in the Aspire dashboard.
4. VS Code reports that the unrelated script's temporary DLL does not exist.

These steps describe the observed workspace. A standalone minimal reproduction has not yet been validated, and the order in which workspace executable projects are returned may affect reproduction.

Expected behavior

The managed WebAssembly debugger should resolve its program/assets using the Blazor project associated with the browser-debug request, rather than an arbitrary executable from the workspace.

An unrelated script should not need to be built or run to debug the Blazor client.

Actual behavior and sanitized evidence

The Aspire extension logs a correct browser-debug request, represented here with anonymized names/paths:

{
  "type": "blazorwasm",
  "request": "attach",
  "name": "Debug Browser: https://localhost:<web-port>",
  "resourceType": "browser",
  "projectPath": "C:\\repo\\Web\\Web.Client\\Web.Client.csproj",
  "url": "https://localhost:<web-port>",
  "browser": "edge"
}

The C# extension then logs a generated managed debug configuration:

{
  "name": "Wasm Managed Debugger",
  "type": "monovsdbg_wasm",
  "request": "launch",
  "args": ["run"],
  "cwd": "${workspaceFolder}",
  "monoDebuggerOptions": {
    "ip": "127.0.0.1",
    "port": "<bridge-port>",
    "platform": "browser",
    "isServer": true
  }
}

This generated configuration has no projectPath or explicit program.

The dialog reports:

launch: program 'C:\Temp\dotnet\runfile\UnrelatedScript-<suffix>\UnrelatedScript.dll' does not exist.

The C# language-server log confirms that the unrelated file-based application was discovered in the workspace.

The saved launch.json contains an Aspire launch configuration and a Blazor WASM attach configuration; neither references the script or its DLL.

The C# extension also attempts to read Properties\launchSettings.json from the workspace root and logs ENOENT. The WebAssembly bridge subsequently logs connection-refused errors. Those may be downstream/separate symptoms, rather than the cause of the wrong program selection.

Source investigation

The installed extension bundle was inspected, and the corresponding program-selection behavior was also checked in the public repository source:

• AssetGenerator.getAssetsPathAndProgram collects WebAssembly asset paths, but returns the program as:

  return [assetsPath, this.executableProjects[0].outputPath];
  

• WorkspaceConfigurationProvider.getAssetsPathAndProgram obtains debug information for folder.uri and delegates to that generator.

• Base configuration provider assigns the returned program to debugConfiguration.program when resolving the browser monovsdbg_wasm configuration.

• In the installed bundle, createManagedDebugConfigurationOnBrowser constructs the managed configuration without forwarding the original browser configuration's projectPath.

Together, these provide a plausible explanation for the observed unrelated-program error: resolution is workspace-wide and selects the first executable rather than the intended Blazor client. The final resolved debug-adapter configuration and actual workspace project ordering were not captured, so that last link is inferred from the source and dialog, not directly logged.

Could the managed browser-debug configuration preserve the requested project identity and resolve the program/assets for that specific project?