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:
To my great surprise, I had to realise that the development of Ninject is hardly progressing anymore. I was a huge fan of Ninject and used it for 8 years without any problems. But without any meaningful progress over the last years, I doubt that Ninject is still a good choice for .Net 6 applications. Does it work in .Net 6+? Maybe, but the issues on GitHub do not give me confidence.
Therefore, we decided to minimise our risks and switch to the default dependency injection container in ASP.Net as part of our migration to .Net 6. Microsoft may stop developing that container as well, but at least it should be part of .Net 8.
After changing the original SSD in my DELL XPS 15 9750 to a Seagate FireCuda 530, I wanted to install Windows 11. Before even the first screen of the installer could load, it crashed with the Blue Screen of Death and the KERNEL_SECURITY_CHECK_FAILURE stop code:
Last week I was in Oslo to attend the NDC conference. I cannot really believe that this was already the 10th NDC Oslo I attended. With 2’600 attendees it was the biggest NDC event ever, but at least for me not the best.
With new versions of Chrome come new security checks. An especially annoying new "feature" I found yesterday in the NDC Oslo workshop. A not fully configured Angular application had a problem that showed up in Chrome as a NET::ERR_CERT_INVALID error.
We recently had a strange behaviour in Azure DevOps: When we run our tests there, the test runner found nearly 16'000 tests. If we run the tests for the same solution in Visual Studio, we only had about 2'000 tests. Where did those additional 14'000 tests come from?