SonarQube: SDK to build plugins for Roslyn Analyzers released

Last month we announced the pre-release version of the SDK for SonarQube Roslyn Analyzer Plugins, the purpose of which is to create a SonarQube plugin for a Roslyn analyzer. We are pleased to announce that version 1 of the SDK is now available.

We have made a few small but significant changes for the release version:

Removed the need for the JDK when generating a plugin

Previously, the SDK compiled Java code on the fly which meant the Java Development Kit had to be installed on the machine. Now, the plugin is created by injecting files into a pre-built jar file so the JDK is no longer required, making the SDK easier to install and use.

Added support for NuGet packages that require license acceptance

NuGet packages can specify that the user accept the license terms for the package. The SDK checks whether the analyzer package or any of its dependencies require license acceptance and presents a list of any that do, together with links to the licenses:

Package requires license acceptance
Package requires license acceptance

Once you have checked the license terms and chosen to accept them you can run the plugin generator again, this time specifying the /acceptLicenses option. The plugin jar will be created, and you will be shown a list of the licenses that have been accepted:

Licenses accepted - plugin created
Licenses accepted – plugin created

Added basic support for remediation data

SonarQube uses the SQALE method to quantify and manage technical debt. One aspect of this is the ability to provide an estimate of the remediation cost for individual rules. By default the generated plugin will only contain rule definitions; it won’t contain any information about the remediation costs. However, it is possible to specify the SQALE information for individual rules in an XML file, and the plugin generator will automatically generate a template XML file for the analyzer being packaged:

SQALE template generated
SQALE template generated

The template file provides placeholders for every rule, and specifies a constant remediation cost for each rule. If you want to provide richer SQALE remediation information, you can copy and manually edit the template file. Once you have updated the file, you can feed it back to the generator using the /sqale:[filename] option. When you look at the resulting rule definitions in SonarQube, you’ll see the remediation values, and these will be used to calculate the technical debt:

Remediation information available in SonarQube
Remediation information available to SonarQube

The SonarQube documentation contains more information on the SQALE method and how it is used in SonarQube.

 

Next steps

If you are a SonarQube administrator and there is a Roslyn analyzer package you want to use, check with the package author to see if they have already create a SonarQube plugin for it (they might have already provided the SQALE information for their rules). Otherwise, you will be able to use the SDK to create a plugin yourself.

We’ve tested the SDK against the most-frequently downloaded NuGet analyzer packages and were able to create SonarQube plugins for them. There a couple of known issues, only one of which is blocking (SFSRAP-32: we don’t currently generate plugins for NuGet packages that just aggregate other packages).

If you discover any issues or have any other feedback, please let us know.

In other news…

In addition to the SDK, we have been working on adding support for a new Connected Mode in SonarLint for Visual Studio to improve the developer experience when using SonarQube to manage technical debt. Read Jean-Marc’s post about the newly-released SonarLint for Visual Studio 2.0 for the details.

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

For bugs, go to the SonarQube Google Group.

0