Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Chiusa
  • Qualcosa non va?
#9,864 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@dibarbet ci sta già lavorando.

Dal 15/10/2026.

  • #9883 di @dibarbet — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
csharp, typescript, vscode, wasm
Ambito
devtools

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

untriaged

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?

Lingua principale
TypeScript
Stelle
3.1k
Fork
740
Merge medio
1g 4h
PR unite (30g)
51

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dotnet/vscode-csharp

Tutte le issue di dotnet/vscode-csharp

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.