Unbound Breakpoints in Blazor WASM Project

Question

I am unable to debug a WASM project in VS 2022, v17.3.6 do to unbound breakpoints. The breakpoints look fine when not running but become an empty circle with the warning sign inside when running the project. The message is “The breakpoint will not currently be hit. Unbound breakpoint”. Other projects within the same solution can be debugged. Three developers on the team have this issue, one does not. All are now on the same version of VS. We tried a slightly older version of VS 2022 (v17.3.4) and it also had this problem.

Below are several ways I tried to fix the problem using many of the suggestions from other posts.

• Cleaned the solution, restarted machine, restarted VS

• Changed debug settings in Tools-Options-Debugging-Symbols to

  • checked Microsoft Symbol Servers

  • checked NuGet.org Symbol Server

  • Load all symbols

• verified launchsettings.json for this setting: "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}"

  • Blazor WASM doesn't hit breakpoint

• verified debug properties of the projects - Build-General-“Debug Symbols, portable across platforms”

• Added code to delay the project start until everything is built

  • VS 2022 17.1.3 The breakpoint will not currently be hit

  • https://learn.microsoft.com/en-us/aspnet/core/blazor/debug?view=aspnetcore-5.0&tabs=visual-studio#breakpoints-in-oninitializedasync-not-hit-1

• Verified https://stackoverflow.com/a/66808469

• Deleted .vs folder for the solution, restarted machine, restarted VS

Peebles

I have had similar issues and sometimes opening the javascript console in the browser helps. Not very practical though. – Coray

Hey guys. In my case I was just in Release mode. So switching from Release to Debug fixed the problem – Optics

Answer 1

The solution in this case had to do with HTTPS. The developers exhibiting the problem (well, 2 out of 3 of them) have a persistent problem when they launch the app, where ASPNET pops up wanting to install a development certificate. They click yes, and it pops up and says it was unsuccessful. This is annoying but otherwise not something the devs worry about since it's been an ongoing annoyance for months if not years.

We tried many things to troubleshoot the problem, including creating a new Blazor WebAssembly project on the machine that couldn't debug. We were able to debug the brand new project! Upon closer examination, we saw that it was created with no authentication. Creating a second project with Individual User Accounts exhibited the same behavior as the production app - breakpoints could not be bound. While tearing apart the code in the non-working new project (with auth) we finally looked at the two launchSettings.json files and found that one of them had two application URLs (https://localhost:XXXX;http://localhost:XXXY), while the other had only the http URL. We deleted the https URL and suddenly the project could be debugged (and the annoying cert popup disappeared, naturally).

We made the same change in the production solution, removing the https application url, and we were able to debug once more. This fixed all three team members who had been unable to debug. Troubleshooting this issue took at least a dozen developer hours and slowed development for several calendar weeks while the team worked around it, so hopefully this helps someone else with the same issue.

Reprehend

What version of VS2022 are you using? – Binky

I cannot wait to try this at home, have you found a work around for https? – Maladjusted

This article covers HTTPS in general for ASP.NET Core. Not a Blazor help doc, but was linked from the Blazor docs. learn.microsoft.com/en-us/aspnet/core/security/… – Acuna

Answer 2

I recently ran into this exact same issue, but wanted to maintain the ability to run under https protocol. Somewhere along the way, I must have had an issue installing the certificate as well. Removing the local dev certs and adding them again solved my issue. Client breakpoints hit after using a proper dev cert. Hoping this can help someone else stuck in the same predicament.

Too erase and add certs:

dotnet dev-certs https --clean
dotnet dev-certs https --trust 

Lowerclassman

Answer 3

I've had the same problem, breakpoint wasn't being hit when I was using 'dotnet watch' launch profile. I was able to start debugging after changing the launch profile back to the launch profile with a commandName: 'Project'.

Imena

Is this with automatically opening a browser window? That's all that works for me and I hate it lol. – Acuna

Answer 4

I'm very new to Blazor and I still don't really know how all the debugging pieces 'fit together'.

It's worth going through these docs below.

1. I didn't have Javascript debugging enabled.
2. My dev certificate seemed to have expired literally today.

https://learn.microsoft.com/en-us/aspnet/core/blazor/debug?view=aspnetcore-7.0&tabs=visual-studio

https://learn.microsoft.com/en-us/aspnet/core/security/enforcing-ssl?view=aspnetcore-7.0&tabs=visual-studio%2Clinux-ubuntu#troubleshoot-certificate-problems-such-as-certificate-not-trusted

One other thing is I can't seem to get it to work reliably unless 'Launch Browser' is set to automatically launch. This is under the 'Launch Profiles'.

Enabling this option allowed me to debug right away. I assume it's something to do with launching Edge in debugging mode, but manually launching in debugging mode doesn't work.

I personally absolutely hate having this turned on. I don't want browser windows opening every time I hit F5. Until I understand how it all works this at least lets me debug.

Acuna

Answer 5

My unbound breakpoints fiasco happened because I unintentionally referenced

<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="7.0.13" PrivateAssets="all">

…in my Blazor WASM .csproj file while updating some packages.

Since I target .NET 6 in the app, the project would run fine, but with no breakpoint support. Reverting back to:

<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="6.0.22" PrivateAssets="all">

…resolved my issue nicely.

Cheshvan