We are pleased to announce that SonarSource has officially released version 2.0 of the SonarQube Scanner for MSBuild and version 4.5 of the SonarQube C# Plugin. The release notes for the scanner and plugin list the bugs that were fixed, but the major change is that together these releases provide support for using third-party Roslyn analyzers with SonarQube.

A pre-release version of the SDK for SonarQube Roslyn Analyzer Plugins is also available – more on that below.

Support for third-party C# Roslyn analyzers

The Roslyn framework makes it easy to write custom code analysis rules for C# and VB code. With these new releases, it is possible to run custom Roslyn analyzers for C# as part of the build and have the results uploaded to SonarQube.

From an experience point of view this is straightforward:

1. Authors of the Roslyn analyzers produce a SonarQube plug-in for their analyzers using the SDK for SonarQube Roslyn Analyzer Plugins
2. The SonarQube administrator installs this plug-in in the same way as any other SonarQube plug-in
3. Build users don’t have to do anything: the SonarQube scanner for MSBuild will automatically set up the required Roslyn analyzers and configure the rulesets, based on the Quality Profile for the SonarQube project.

The blog announcing the release of the previous version gave an overview of the architecture. Here, I’ll describe how the various pieces fit together from the view points of the two main actors involved – the SonarQube administrator, and the Roslyn analyzer author. I’ll then describe in more detail what happens at runtime when an analysis build is performed.

SonarQube administrators

From the point of view of SonarQube administrators, the Roslyn-specific plugins are no different from any other SonarQube plugin. Administrator can choose and install the plugins they want to use, then select which rules to apply in each quality profile just as they normally would. They don’t need to know anything about Roslyn, and they don’t need to perform any additional manual configuration or setup on the machines that will perform the analysis.

The only caveat is the not unreasonable one that the machine on which the analysis is performed must support running Roslyn analyzers i.e. the build must be using MSBuild 14.0 or later.

Roslyn analyzer authors

Just as SonarQube administrators shouldn’t need to know about Roslyn analyzers, we’ve tried to limit the amount Roslyn analyzer authors need to know about creating SonarQube plugins – they shouldn’t need to be Java coders or to understand the SonarQube extensibility model, which is where the SDK mentioned earlier comes in. The SDK provides tooling to automatically generate a SonarQube plugin that wraps a Roslyn analyzer.

At this point the SDK is very simple: it’s a single exe that you point at an analyzer NuGet package, and it produces a jar file containing the SonarQube plugin. This is currently no way to customise the jar that is produced. See the project README for more information.

I’ve described an idealised view here in which the plugin jar is created and published by the analyzer author. However, there is nothing to stop a SonarQube administrator from using the SDK to create a plugin if one isn’t already available for a particular analyzer.

Under the covers

At runtime, the scanner, C# plugin and generated plugins co-operate to setup, configure and execute the rules configured in the Quality Profile for the SonarQube project.

Runtime component collaboration

The sequence of actions at runtime is as follows:

• The scanner requests information about the analyzers and ruleset to use during the build
• The C# plugin inspects all of the installed plugins to work out which ones are for Roslyn analyzers. It collects metadata from these plugins, along with a ruleset it has generated by looking at the configured Quality Profile, and it returns the requested data to the scanner
• The scanner downloads the necessary analyzer dlls from the SonarQube server and configures MSBuild to use them and the supplied ruleset. As in previous versions, the scanner does not make permanent changes to the MSBuild projects. Instead, it intercedes during the build to dynamically change the ruleset and set of analyzers that are used, disregarding any that are specified in the project file.
• The compilation phase then executes as normal. The compiler calls the specified Roslyn analyzers and produces an error report containing analysis errors and warnings for all of the analyzers.
• Finally, the scanner passes this report to the C# plugin, which uploads the errors and warnings to SonarQube as issues.

Next steps

Now that the infrastructure work on the scanner and C# plugin has been completed, we can turn our attention to improving the authoring experience for creating the plugin jars. The current SDK preview (version 0.9) will generate a working plugin but has a number of rough edges and is missing a couple of important features, such as support for analyzers that require license acceptance and the ability to provide remediation costs for new diagnostic rules. We’ll address these in the version 1.0 release.

In my previous post I mentioned that we are also working on improving the integration between SonarQube and the Visual Studio IDE. This work is progressing well and an initial version should be available in the near future.

As ever, comments, feedback and suggestions are welcome.

(Special thanks to Marcel and Markus for finding and diagnosing a couple of early issues with the SDK)

For support, look on StackOverflow for questions tagged with sonarqube-msbuild-runner

For bugs, go to the SonarQube Google Group.