.NET 6 Surprises

A few weeks ago, we upgraded one of our projects from .NET 5 to .NET 6, since .NET 5 was nearing end of support. In this process, we ran into a few hurdles. This post will go through a few of them that were a bit unexpected, and why we ran into them.

AccessTokenValidation deprecated

This isn’t completely related to .NET 6 in itself, but we ran into the issue during the upgrade. While upgrading our Nuget dependencies, we had some trouble with mismatching version numbers on transient dependencies. While we tried to upgrade the IdentityModel package to a newer version, AccessTokenValidation had a dependency to an older version. It turned out that AccessTokenValidation had been deprecated since we added it. This was solved by removing the dependency by simply substituting a call to AddIdentityServerAuthentication with a call to AddJwtBearer. We don’t use Introspection to validate tokens in our solution, but it is possible to combine JwtBearer and Introspection using the ForwardDefaultSelection option.

DateTime handling in Npgsql 6

Once all dependencies were handled and the application could run properly, we ran into another problem. We got an exception when trying to save some database entries. This was because of a breaking change in Npgsql: DateTime objects with Kind=Local or Unknown are no longer supported. In one of our applications, we create all objects ourselves, so it was no big deal to change them to conform with the new behavior.

In another of our applications, we save objects which are generated by an external library. In this case, the easiest solution was to set the Npgsql.EnableLegacyTimestampBehavior flag rather than converting the timestamps.

SSL Modes in Npgsql 6

A third issue appeared when we deployed our application to our dev environment and it crashed on startup. This was due to another breaking change in Npgsql: it no longer supports SSL Mode=Require without also adding Trust Server Certificate=true. In our case, we want to validate our certificates, so we set SSL Mode=VerifyFull.

What we’ve learned

One of these issues was disovered while testing the application manually and another when the application was deployed to our dev environment. Neither is of course ideal - we want to catch these issue much earlier. While the breaking changes in Npgsql were well documented, it can be difficult to keep track of whether or not a particular breaking change will affect a system, and how.

This project is still in a very early stage. We don’t have and production users and business demands are not fully specified yet. While we have decent unit test coverage and a few e2e tests, we’re still in the process of setting up a proper test suite. For example, we recently added some Cypress tests. There will be more posts in the future about how we work with testing and deployment, so stay tuned!