As the final post of the series on our .Net 6 migration, we look at our experience of running our new .Net 6 application in production. You can find the other parts of the mini-series here:
While our migration from .Net 4.8 to .Net 6 worked better than expected, we found a lot of annoying incompatibilities that took us hours to figure out. In this post I collect the 10 most frustrating differences to give you an overview on what to expect when you upgrade your applications to .Net 6.
This is part 2 of the mini-series on the .Net 6 migration:
For our most important application, the migration from .Net 4.8 to .Net 6 was an adventure. Now that it successfully runs in production, I take the opportunity to share our experience with the migration of our biggest application and the obstacles we run into.
This is part 1 of the mini-series on the .Net 6 migration:
If I run into tasks that I must repeat countless times, I try to automate them as much as possible. Since we always add the same dependencies to our test projects, we thought it would be a great idea to create a project template that has all the necessary settings already in place. Let us figure out how little effort it takes to create our own project templates for dotnet, Visual Studio and Rider.
While updating to Bootstrap 5, I had a few elements that did not look as they should. The Chrome Developer Tools are great to show you all the different styles and where they are from, but if you need to figure out what part exactly is missing, the Developer Tools do not help that much.
The code coverage is an important part of the quality metrics of SonarQube. Unfortunately, SonarQube needs some extra steps to use our code coverage reports from our Azure DevOps pipeline as part of its code analysis.
As in the last posts on code coverage, we again use Coverlet and ReportGenerator as part of our Azure DevOps build pipeline.
Last week we used Coverlet and ReportGenerator to collect code coverage on our development machines. In this post we continue this journey and extend our build pipelines to get a nice coverage report with every continuous integration build.
For .Net 4.8 it was enough to install Visual Studio Enterprise Edition on the build server and check the box for code coverage in the Testing task of Azure DevOps. The build agent then collected the coverage data and published it as part of your builds. Unfortunately, for .Net 6 this no longer works, and we need to go through a lot more steps.
There are a handful projects for code coverage that support .Net "core", but not every project is still under active development. Be careful when you select a coverage tool and make sure that there is still some activity going on.
A side effect we noticed after the migration to .Net 6 was that the test task in Azure DevOps took a lot longer than before. The test execution itself did not change much, but the dotnet test task had much more overhead than vstest. As an example, the test task took 4m 48s, while the test execution only took 1m 34s – giving us an overhead of 3m 14s or roughly 75% of the total time:
This may be one of the strangest errors I got from Visual Studio 2022 (17.6.3) in a long time:
