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!
There’s a lot of flexibility in how you can use authorisation rules in Razor components*, but a frustration of this approach is that it seems like you have to slap @attribute [Authorize(Policy = "PolicyName")] at the top or every page with no clear way of applying a given policy to a whole folder of .razor files. After much research and testing, I’ve found how to go about it!
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)!
Blazorise is an excellent library that I’ve been using a lot lately. While it has great support for declaring custom visual themes, you’ll occasionally run into situations where what you’re trying to do isn’t fully supported.
Take this super contrived example: I want to set the shadow on a div to use the primary colour defined in my theme, but there’s no attribute in Blazorise to do this directly (at time of writing). I could hard-code the colour to the same hex value as what I’ve set in my theme, but not only is this generally bad practice (since it’s easy to update one value and not the other), it locks you into only one colour even though the theme can be modified dynamically during runtime. So how can we access our Blazorise theme values in custom CSS?
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?
I’ve used SSH.NET a lot over the years to send and receive files using SFTP and it’s a very flexible and practical library, but the documentation can be a bit thin on the ground when you’re looking to use some of the more esoteric features it has.
As an example, I recently ran into an issue where I was connecting to a remote server and the host fingerprint I was receiving through SSH.NET didn’t match the one that I expected to see (and could see in WinSCP). After verifying that I was using the same connection settings on both and more than a little spelunking through the SSH.NET source code I found that by default the host key algorithms used by the stable release of SSH.NET that I was on (2016.1.0) are RSA and DSA, while WinSCP uses Ed25519. For my purposes I needed to use Ed25519 in SSH.NET as well even though the SFTP host also supported these other algorithms.