SonarSource have officially released SonarQube C# Plugin 4.4 and version 1.1 of the SonarQube Scanner for MSBuild. There have been no updates to the scanner documentation in this release, other that updating the version number to make it clear they relate to version 1.1 of the SonarQube Scanner for MSBuild.
As usual, we’ve fixed a few bugs (see here for the full list) and updated the SonarLint rules so they are equivalent to those in SonarLint version 1.6. However, main change is to when and how the SonarLint rules are being run.
Running SonarLint during the build phase in MSBuild 14.0
The SonarQube Scanner for MSBuild (formerly known as the MSBuild SonarQube Runner) executes in three phases: pre-build (the “begin analysis” phase), build, and post-build (the “end analysis” phase). In previous versions the SonarLint C# analysis rules were run post-build. However, if you are building using MSBuild 14.0 then these rules will now be run during the build phase. This gives more accurate results than if the analysis is carried out post-build.
When the analysis is carried out in post-build phase the code files are analyzed one at a time so the analysis rules are only ever looking at incomplete sections of code. As a result, there may be errors that cannot be detected, or there may be false positives returned for partial classes that are split across multiple files. Carrying out the analysis during the build phase improves the accuracy by allowing the diagnostic rules to assess all of the code in the project at once. It also means that the results will be consistent with those for the same SonarLint rules when run in the IDE.
If you are building using MSBuild 12.0 then there will be no change to the existing behavior; the SonarLint rules will continue to be run post-build. However, the C# plugin will warn you that you can get better analysis results by switching to MSBuild 14.0.
The diagram below summarizes what happens in each of three phases in older versions of the C# plugin, in the new version 4.4, and gives an indication of what will be available in the future.
Diagram: past, present and future (click to see full size)
Next steps – supporting any Roslyn analyzer
The reason the SonarLint rules can be run as part of the build in MSBuild 14 is that they are written as Roslyn analyzers, and the standard MSBuild 14.0 targets support executing Roslyn analyzers as part of the compile task.
The Roslyn framework has made it much simpler to write new analysis rules, and new analyzers are being created both by Microsoft and by the community. Consequently, we want to be able to run any Roslyn analyzer during the build and upload the issues to SonarQube, not just the SonarLint rules. The SonarQube Scanner for MSBuild v1.1/C# plugin v4.4 releases are the first step to being able to do this.
Fully supporting any Roslyn analyzer will require further changes to both the scanner and C# plugin. However, it will also require some work to be done for each analyzer that is to be integrated into SonarQube. The diagram below gives an overview of what is required:
Diagram: bridging the gap between SonarQube and Roslyn (click to see full size)
New rules can be added to SonarQube by writing plugins in Java, whereas Roslyn analyzers are written in managed code. Fortunately, there is a reasonably close mapping between Roslyn analyzer rules and SonarQube rules.
In collaboration with SonarSource we’ve started working on tooling to automatically generate a basic SonarQube plugin for a Roslyn analyzer. With a bit more effort (i.e. by providing additional, richer metadata to describe the rules and the technical debt associated with them) it will be possible to produce a more polished plugin that provides a better experience in SonarQube.
The code is in the SonarQube Roslyn SDK repo on GitHub. This work is still at an early stage, but you can head over to the repo to try out what we’ve done so far or to monitor the progress. In parallel, we are working on improving the integration between SonarQube and the Visual Studio IDE so that developers can choose to use the same configuration in the IDE as that specified in SonarQube.
As ever, we welcome comments and feedback. If you have a support question, head over to StackOverflow and have a look at the questions tagged with sonarqube and msbuild to see if there is already a solution there, and if not, please ask. Bugs can be reported via the SonarQube Google Group.