12

Debugging the Code

In this chapter, we will take a look at debugging. The debugging experience of Blazor is a good one; hopefully, you haven’t gotten stuck earlier on in the book and had to jump to this chapter.

Debugging code is an excellent way to solve bugs, understand the workflow, or look at specific values. Blazor has three different ways to debug code, and we will look at each one.

In this chapter, we will cover the following:

• Making things break
• Debugging Blazor Server
• Debugging Blazor WebAssembly
• Debugging Blazor WebAssembly in the browser
• Hot Reload

To debug something, we should first make something break!

Technical requirements

Make sure you have followed the previous chapters or use the Chapter11 folder as a starting point.

You can find the source code for this chapter’s end result at https://github.com/PacktPublishing/Web-Development-with-Blazor-Second-Edition/tree/main/Chapter12.

Making things break

Edsger W. Dijkstra once said,

“If debugging is the process of removing software bugs, then programming must be the process of putting them in.”

This is definitely true in this section because we will add a page that will throw an exception:

1. In the Components project, in the Pages folder, create a new Razor component called ThrowException.razor.
2. Replace the contents of the file with the following code block:

   @page "/ThrowException"
   <button @onclick="@(()=> {throw new Exception("Something is broken"); })">Throw an exception</button>
   

This page shows a button, and when you press it, it throws an exception.

Great! We have our application’s Ivan Drago (he wants to break you, but we might just beat him with some fancy debugging).

The next step is to take a look at Blazor Server debugging.

Debugging Blazor Server

If you have debugged any .NET application in the past, you will feel right at home. Don’t worry; we will go through it if you haven’t. Debugging Blazor Server is just as we might expect and is the best debugging experience of the three different types we will cover.

I usually keep my Razor pages in a shared library, and while building my project, I use Blazor Server for two reasons. First, running the project is a bit faster, and second, the debugging experience is better.

Let’s give it a try!

1. Set BlazorServer as a startup project.
2. Press F5 to start the project (this time with debugging).
3. Using the web browser, navigate to https://localhost:portnumber/throwexception (the port number may vary).
4. Press F12 to show the web browser developer tools.
5. In the developer tools, click Console.
6. Click the Throw exception button on our page.

   At this point, Visual Studio should request focus and it should show the exception as shown in Figure 12.1:

   

   Figure 12.1: Exception in Visual Studio

7. Press F5 to continue and switch back to the web browser. We should now be able to see the exception message in the developer tools as shown in Figure 12.2:

Figure 12.2: Exception in the web browser

As we can see in Figure 12.1 and Figure 12.2, we get the exception both in Visual Studio while debugging and also in the developer tools.

This makes it quite easy to find the problem if there is an exception in an app in production (perish the thought) – that feature has saved us many times.

Now let’s try a breakpoint:

1. In Visual Studio, open Components/Pages/Index.razor.
2. Anywhere in the LoadPosts method, set a breakpoint by clicking the leftmost border (making a red dot appear). We can also add a breakpoint by pressing F9.
3. Go back to the web browser and navigate to https://localhost:portnumber/ (the port number may vary).

Visual Studio should now hit the breakpoint, and by hovering over variables, we should be able to see the current values.

Both breakpoints and exception debugging work as we might expect. Next, we will take a look at debugging Blazor WebAssembly.

Debugging Blazor WebAssembly

Blazor WebAssembly can, of course, be debugged as well, but there are some things we need to think about. Since we have our exception page in our shared library, we can go straight into debugging.

But let’s start with breakpoints:

1. Set BlazorWebAssembly.Server as the startup project.
2. Press F5 to debug the project.

Here we can notice the first difference – assuming we still have the breakpoint we set in the Debugging Blazor Server section (in the LoadPosts method), the breakpoint did not get hit.

Breakpoints won’t get hit on the initial page load in Blazor WebAssembly. We need to navigate to another page and back to the index page again for it to hit.

We can’t just change the URL, as we could in Blazor Server, simply because that will reload the app again and not trigger the breakpoint because it was an initial page load.

Debugging Blazor WebAssembly is made possible by the following line of code in the launchSettings.json file:

"inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}"

But it is supplied for us when we create the project, so we don’t need to add that manually.

We can also put breakpoints in our BlazorWebAssembly.Server server project if we want to, and they will get hit just as we would expect.

Now let’s see what happens with our exception:

1. In the web browser, navigate to https://localhost:portnumber/throwexception.
2. Click the Throw exception button.
3. The unhandled exception won’t get hit in Visual Studio. We get the exception in the developer tools in the web browser, as shown in Figure 12.3:

Figure 12.3: WebAssembly error

The debugging experience in Blazor WebAssembly is not as polished as with Blazor Server but it is polished enough to get the job done.

We have one method left to explore – debugging in the web browser.

Debugging Blazor WebAssembly in the web browser

The first debugging experience for Blazor WebAssembly was the ability to debug right in the web browser:

1. In Visual Studio, start the project by pressing Ctrl + F5 (run without debugging).
2. In the web browser, press Shift + Alt + D.

   We will get an error message with instructions on how to start the web browser in debug mode.

   I am running Edge, so the way to start Edge would be something like this:

   msedge --remote-debugging-port=9222 --user-data-dir="C:UsersJimmyAppDataLocalTemplazor-edge-debug" --no-first-run https://localhost:5001/
   

   The port and user-data-dir values will differ from the example above. Copy the command from your web browser.

3. Press Win + R and paste the command.
4. A new instance of Chrome or Edge will open. In this new instance, press Shift + Alt + D.
5. We should now see a source tab containing C# code from our project. From here, we can put breakpoints that will be hit and hover over variables.

The debug UI can be seen in Figure 12.4:

Figure 12.4: Screenshot of the in-browser debug

Debugging C# code in the browser is pretty amazing, but since we have been directly debugging in Visual Studio, I don’t see much use for this kind of debugging.

Next, we will look at something that might not fall under debugging but is useful while developing Blazor apps.

Hot Reload

In Visual Studio and the dotnet CLI, we can enable Hot Reload. This means that as soon as we make changes in our application, our Blazor app will automatically get reloaded, and we will (in most cases) not lose the state.

To set this up, do the following:

1. In Visual Studio, there is a small fire icon. We can use this button to trigger hot reload manually.

   It is only clickable when the application is running (with or without debugging).

   We can also click on the small arrow just to the right of the fire icon and select Hot Reload on File Save.

2. Select the Hot Reload on File Save option.
3. Start the project by pressing Ctrl + F5.
4. In the web browser, bring up the counter page by adding /counter to the URL.
5. Make a change to the Components/Pages/Counter.razor file and click Save.

Our web browser should now reload, and the change will be shown.

At the time of writing, Hot Reload does save time and is pretty amazing. However, there are some cases where our site will behave oddly, and then we need to rebuild. Therefore, you need to keep in mind that if there is an unexplainable issue, you will need to build the project again.

This also works from the command line by running the following command:

dotnet watch

There are a couple of limitations to this method, though:

• It doesn’t work with Blazor WebAssembly running an ASP.NET server backend (as we have in our project). For this to work, we need to reload the browser manually.
• The state of the application will restart.
• Changes in a shared project won’t be reflected.

So, for our setup, this feature isn’t very beneficial, but it is really good if our project doesn’t fall into any of the previously mentioned limitations.

Summary

This chapter looked at different ways to debug our Blazor application. There will always be moments when we need to step through the code to find a bug or see what is happening. When these moments are upon us, Visual Studio delivers world-class functionality to help us achieve our goals.

The nice thing is that debugging Blazor applications, whether it’s Blazor Server or Blazor WebAssembly, will work as expected from a Microsoft product. We get C# errors that are (in most cases) easy to understand and solve.

In the next chapter, we will look at testing our Blazor components.