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.