-
Notifications
You must be signed in to change notification settings - Fork 10.4k
Description
Is there an existing issue for this?
- I have searched the existing issuesTo pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
Describe the bug
When running Blazor WebAssembly Static Web Apps in Visual Studio using the SWA CLI and browsing to http://localhost:4280 (as per swa start) with Microsoft.AspNetCore.Components.WebAssembly.DevServer version 7.0.10+, the Visual Studio breakpoints have an Unbounded breakpoint warning.
This scenario worked in Microsoft.AspNetCore.Components.WebAssembly.DevServer version 7.0.9.
Expected Behavior
Breakpoints should be reached in 7.0.10/7.0.11 just as they were in 7.0.9 (and before)
Steps To Reproduce
- This version uses Microsoft.AspNetCore.Components.WebAssembly.DevServer 7.0.0, however upgrading to 7.0.9 will also demonstrate the correct behavior.
- Install the SWA CLI
- Open the Blazor-Starter project in Visual Studio 2022
- Update the Client\Properties\launchSettings.json to include the line
"launchUrl": "http://localhost:4280",
the full file should look like
{
"iisSettings": {
"windowsAuthentication": false,
"anonymousAuthentication": true,
"iisExpress": {
"applicationUrl": "http://localhost:46660",
"sslPort": 44350
}
},
"profiles": {
"BlazorApp.Client": {
"commandName": "Project",
"dotnetRunMessages": true,
"launchBrowser": true,
"launchUrl": "http://localhost:4280",
"inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}",
"applicationUrl": "http://localhost:5000",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
},
"IIS Express": {
"commandName": "IISExpress",
"launchBrowser": true,
"inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
}
}
}
- Within the SWA directory start the SWA CLI with the command:
swa start http://localhost:5000
- Start debugging the Client in Visual Studio
- Add a breakpoint and ensure it can be reached (e.g. counter++ in counter.razor)

- Upgrade Microsoft.AspNetCore.Components.WebAssembly.DevServer to version 7.0.10 (note this is still broken in 7.0.11)
- Start debugging the Client in Visual Studio
- You will see that the breakpoint will now have an Unbounded Breakpoint warning and will not be reached.

Exceptions (if any)
No response
.NET Version
7.0.401
Anything else?
dotnet --info
.NET SDK:
Version: 7.0.401
Commit: eb26aacfec
Runtime Environment:
OS Name: Windows
OS Version: 10.0.22621
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\7.0.401\
Host:
Version: 7.0.11
Architecture: x64
Commit: ecb34f85ec
.NET SDKs installed:
7.0.401 [C:\Program Files\dotnet\sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.22 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]
Environment variables:
Not set
global.json file:
Not found
Learn more:
https://aka.ms/dotnet/info
Download .NET:
https://aka.ms/dotnet/download
Metadata
Metadata
Assignees
Labels
Type
Projects
Status
Activity
ghost commentedon Sep 27, 2023
To learn more about what this message means, what to expect next, and how this issue will be handled you can read our Triage Process document.
We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. Because it's not immediately obvious what is causing this behavior, we would like to keep this around to collect more feedback, which can later help us determine how to handle this. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact work.
danroth27 commentedon Nov 20, 2023
@thomasgauvin Have you heard any additional feedback on this Blazor WebAssembly debugging problem from Azure SWA users attempting to use the SWA CLI?
mkArtakMSFT commentedon Jan 2, 2024
Closing as we have no enough evidence that this has regressed. If anyone else faces this issue, please file a new issue.
@thaystg FYI, in case you may know of a reason for this to regress.