I wanted to configure ASP.NET Core Data Protection to persist keys to Redis using the Microsoft.AspNetCore.DataProtection.StackExchangeRedis package. Using Aspire, it was easy to set up a Redis container in development, and the hosting package makes it simple to add a Redis client with logging, metrics, and resilience. The problem was that PersistKeysToStackExchangeRedis only accepts a concrete IConnectionMultiplexer instance. There is no overload that takes a factory or resolves from the container, so the setup looked like this:

In a lot of projects I have been on I’ve seen the following approaches when it comes to application logging in test:

1. The most popular option: It is completely ignored, either by pumping it into a mock or a NullLogger
2. It is tested by verifying that the correct log messages are written. This is usually done to satisfy a ‘strict’ mocking framework.

Neither of these options are ideal in my opinion. The first option totally hides the logging, making it hard to see if it is actually valuable. The second option adds too much noise into the tests, since verifying that the message is written doesn’t tell me much.

Recently I wanted to verify that my data access layer could properly read and write to a SQL Server database, and I wanted to have these tests automated. I wanted to answer these questions:

1. Can my DbContext roundtrip entities to the database and back?
2. Does the schema in my migration scripts match the expected schema in my code? (follows from 1)
3. Can my migration scripts be applied to the database correctly?

Since I was using SQL Server I could utilize SQL Server LocalDB that comes with Visual Studio. To keep performance acceptable I do not want to create and destroy a database for each test, so I need a way to reset the database after a test has run.

Recently at work, I had to implement some functionality that required the use of Guid identifiers that were stored in SQL Server. The Guids were generated in the application and used as an alternative key / external identifier for other systems. To avoid excessive index fragmentation, we opted to use the GuidComb variant using a generator from the NHibernate project.

The GuidCombGenerator generates Guid values that have a timestamp embedded into the last 6 bytes. For example:

As a side project, I’ve been working on my implementation of a FoundationDB client for .NET. I want to have tests to verify things are working properly, and for local development that isn’t such a problem since I usually have a FoundationDB server installed. However, when I want to run these tests on a build server I do not want to enforce installing FoundationDB in the build environment, things should just work. Also when people check out the repository and want to run the tests, they shouldn’t strictly need to have FoundationDB installed.