I recently encountered an issue while trying to debug a Blazor client project. Googling any Blazor debugging issues returns lots of results, all of them related to breakpoints not being hit. However, my problem was that despite hitting breakpoints, no variable values etc. could be examined. So debugging did nothing beyond pausing execution.
Our first check was against Microsoft’s instructions for debugging Blazor, but a careful run through showed that everything was already in place in our development environments.
To rule out any Visual Studio installation/configuration problems, we next span up a Visual Studio template Blazor solution, complete with client component. During the setup, we chose the options closest to the solution that had the issue. Firing up a debugging session, adding a breakpoint to the Client project (in this case, the Counter example that comes with a Blazor template), was enough to show it worked without problems. The breakpoint was hit, AND I was able to see the state of variables.
At this point became all too clear that we had the answer nobody wanted – we must have broken the functionality with a change somewhere along the line. It was time to grab a big coffee and go fishing through the repo history.
I decided to start by identifying the biggest changes that had been made to the solution, reasoning they were most likely to be responsible for something like this breaking. It was then a matter of resetting my local repo to versions immediately before and after these changes to see if I could identify the changeset that broke it. Luckily, an early guess paid off, and it became clear that debugging worked fine in versions prior to our migration to .Net 5.0.
We had followed the instructions supplied by Microsoft when migrating, but something wasn’t right.
After a few file compares between certain key files (since it’s a .Net web application, we began with the startup project’s csproj file, Program.cs, Startup.cs and launchSettings.json), we finally found the issue.
In updating assemblies to .NET 5.0 versions, some had simply been missed, and remained on .Net Core 3.1 versions. This wasn’t enough to cause any issues we’d noticed at runtime, but was enough to cause the strange debugging behaviour. Simply updating the package references to versions > 5.0, doing a clean and rebuild, and running the application again was enough to show that debugging was back to normal.