SignalR is a fantastic library for enabling real-time applications, especially when using MVC or Blazor in ASP.NET Core. I’ve been using it a lot lately and while it is an excellent way to make your application feel super responsive through messaging and remote procedure calls, there are certain aspects of how the whole thing hangs together which can be very confusing.
This blog post is designed to give you an overview of the different parts of a “standard” SignalR implementation and explain how messages flow through the system. I won’t be going into details on how SignalR works internally (if I even could!), instead choosing to focus on the parts that you’ll come into direct contact with. This blog post also isn’t designed as a tutorial since there is great documentation for implementing SignalR already (which is where I sourced the below code examples from!).
If you’ve used Blazor for a while you may have run into the following (pretty unhelpful) error message where the page router is throwing a NullReferenceException:
The worst part is that I always seem to run into this error after making a bunch of changes and then having no idea exactly what I did to break the build (yeah I know, I should probably run my code more while making changes).
I’ve managed to form a general idea of why the error is thrown and have found two concrete situations that reproducibly cause the issue, so I’ve finally written them down for when I inevitably run into this situation again!
I’ve noticed an issue recently after upgrading a few Blazor projects from .NET 5 to .NET 6 where the UI flashes after every call to StateHasChanged. Something like this:
Yeah, that’s not annoying at all. Unfortunately it was happening in quite a few different places and was pretty darn noticeable, so it looked like I was going to have to dive in and figure out what exactly was causing this to go wrong (despite working perfectly in .NET 5)!
I’m sure I’m not the only one that has “temporarily” stored passwords, application keys or other development secrets in appsettings.json simply because it was easier or faster than doing it the right way (although if I am, this first sentence will surely come back to haunt me).
I get it. It happens! This blog post actually comes from my efforts to update a project I’m working on with some friends so that we’ve got a more consistent approach to keeping secrets… secret.
So how are we going to go about this? We’ll be using Secret Manager, a fantastically helpful tool built into the configuration API in ASP.NET Core that will let us keep the secrets out of appsettings while not require a change to how we access the settings in code. Sound good?