Detect Blazor WebAssembly apps without inspectUri#9507
Open
javiercn wants to merge 3 commits into
Open
Conversation
The .NET templates no longer emit inspectUri in launchSettings.json, which broke detection of Blazor WebAssembly apps and prevented .razor breakpoints from being hit when debugging (dotnet/aspnetcore#67507). Replace the inspectUri read with static, project-based signals: - Standalone: the Microsoft.NET.Sdk.BlazorWebAssembly SDK project. - Hosted: an executable Web SDK host referencing the Microsoft.AspNetCore.Components.WebAssembly.Server package. Add an 'enableWebAssemblyDebugging' launchSettings.json profile escape hatch that unconditionally forces WebAssembly debugging for non-standard layouts. Templates do not set it by default. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Updates Blazor WebAssembly debug configuration selection to no longer depend on inspectUri in launchSettings.json (which is no longer emitted by newer .NET templates). Instead, it uses static project signals (SDK type + hosted server package reference) plus a enableWebAssemblyDebugging: true launch profile escape hatch, so the extension can still pick the correct blazorwasm debug configuration.
Changes:
- Replace
inspectUri-based detection withgetBlazorWebAssemblyDebugInfousing project SDK markers and a hosted-server package reference check. - Add
enableWebAssemblyDebugginglaunch profile escape hatch support and unit tests for detection behavior. - Wire the new detection into both OmniSharp and Roslyn workspace debug info providers and document the change in the changelog.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| test/omnisharp/omnisharpUnitTests/blazorWebAssemblyDetection.test.ts | Adds unit coverage for hosted/standalone detection and the escape hatch behavior. |
| src/shared/utils.ts | Implements new static Blazor WASM detection helpers and the launchSettings escape hatch reader. |
| src/omnisharp/utils.ts | Switches OmniSharp workspace info enrichment to the new detection API. |
| src/lsptoolshost/debugger/roslynWorkspaceDebugConfigurationProvider.ts | Switches Roslyn workspace debug info enrichment to the new detection API. |
| CHANGELOG.md | Notes the detection change and escape hatch for the next prerelease line. |
Keep the original inspectUri check and isBlazorWebAssemblyHosted logic intact and layer the newer heuristics on top instead of replacing them: - isBlazorWebAssemblyProject also recognizes the enableWebAssemblyDebugging launch profile escape hatch (matched with indexOf so commented launchSettings.json still works). - Add isBlazorWebAssemblyHostedServer for the WebAssembly.Server package signal, OR-ed with the original hosted heuristic at the call sites. - Standalone additionally recognizes WebAssembly SDK projects. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
|
LGTM |
Per reviewer guidance, detect the launchSettings signals with the existing jsonc-parser instead of raw text matching. This tolerates comments/trailing commas, avoids false positives from commented-out properties, and checks the actual boolean value of the enableWebAssemblyDebugging escape hatch. Also remove the CHANGELOG.md entry: 2.151 has shipped and the 2.152 release notes are generated automatically from PRs. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
Author
|
Thanks for the review! Addressed in d3136cf:
|
Member
Author
|
🆙 📅 |
Member
Author
|
@gregg-miskelly is there anything else we need to do to get this merged? (never worked on this repo) /cc: @thaystg |
gregg-miskelly
approved these changes
Jul 8, 2026
Contributor
|
LGTM. @javiercn should I hit the merge button? |
Member
Author
|
@gregg-miskelly Yes please. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The .NET 11 templates no longer emit
inspectUriinlaunchSettings.json(for both standalone Blazor WebAssembly and Blazor Web App WebAssembly host projects). The extension detected Blazor WebAssembly apps by readinginspectUrifromlaunchSettings.json(src/shared/utils.ts), so detection now fails: theblazorwasmdebug configuration is never selected, the browser JS debugger / ws-proxy is not attached, and.razorbreakpoints are not hit.Fixes the extension side of dotnet/aspnetcore#67507.
Where the check runs (host vs. WASM project)
For hosted apps the debug launch (and thus detection) runs on the server/host project, which has no WebAssembly SDK marker of its own.
inspectUriin the host''slaunchSettings.jsonwas the only signal. For standalone, the single project is the WebAssembly-SDK project itself.Change (additive)
The existing checks are kept intact and the newer heuristics are layered on top (opt-in / additive), so older projects keep working exactly as before:
isBlazorWebAssemblyProjectkeeps the originalinspectUricheck and additionally recognizes anenableWebAssemblyDebugginglaunch profile flag. This is the escape hatch: it unconditionally signals the need for WebAssembly debugging for non-standard layouts. It is matched withindexOf(notJSON.parse) becauselaunchSettings.jsonmay contain comments. Templates do not set it by default.isBlazorWebAssemblyHostedServer: recognizes a hosted host as an executableMicrosoft.NET.Sdk.Webproject that referencesMicrosoft.AspNetCore.Components.WebAssembly.Server(the package that provides the WebAssembly debugging middleware). OR-ed with the originalisBlazorWebAssemblyHostedheuristic at the call sites.Microsoft.NET.Sdk.BlazorWebAssemblySDK projects (already surfaced byisWebProject), OR-ed with the original signal. A hosted project is never standalone.The original
isBlazorWebAssemblyHosted(including itstargetsDotnetCoreguard) is unchanged.The runtime
inspectUrihandling inblazorDebugConfigurationProvider.tsis intentionally left as-is: it already defaults the ws-proxy URL wheninspectUriis absent, so debugging works once theblazorwasmconfig type is selected.Testing
test/omnisharp/omnisharpUnitTests/blazorWebAssemblyDetection.test.tscovering the originalinspectUripath, theenableWebAssemblyDebuggingescape hatch (including commented JSON), theWebAssembly.Serverhost heuristic, and the WebAssembly SDK signal.tsc --noEmit, eslint, existingassets.test.ts(48 tests), and the new tests all pass.