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.
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
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
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
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!