Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đã đóng
  • Có gì không ổn?
#9,864 3 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@dibarbet đang làm issue này rồi.

Từ ngày 15/10/2026.

  • #9883 của @dibarbet — đang mở

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
csharp, typescript, vscode, wasm
Lĩnh vực
devtools

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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?

Ngôn ngữ chính
TypeScript
Star
3.1k
Fork
741
Merge trung bình
1 ngày 8 giờ
Pull request đã merge (30 ngày)
59

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của dotnet/vscode-csharp

Tất cả issue của dotnet/vscode-csharp

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.