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}"
-
verified debug properties of the projects – Build-General-“Debug Symbols, portable across platforms”
-
Added code to delay the project start until everything is built
-
Verified https://stackoverflow.com/a/66808469
-
Deleted .vs folder for the solution, restarted machine, restarted VS
2
Answers
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’.
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.