Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Export/Import Visual Studio 2015 rule set into SonarQube

Environment: We are building C# code within Visual Studio 2015 and generating CodeAnalysis report using default ruleset available within Visual Studio 2015.

Problem Statement: While running same code into SonarQube integrated with our Continuous integration environment Jenkins, we are getting different Code analysis report, so we want to import default rule set of Visual studio 2015 to be used within SonarQube 5.6 or later (I am ready to upgrade Sonar if there is solution). But problem is SonarQube is not able to recognize ruleset starting with CS, like..

<Rules AnalyzerId="Microsoft.CodeAnalysis.CSharp" RuleNamespace="Microsoft.CodeAnalysis.CSharp">
<Rule Id="AD0001" Action="Error" />
<Rule Id="CS0028" Action="Error" />
<Rule Id="CS0078" Action="Error" />
<Rule Id="CS0105" Action="Error" />
<Rule Id="CS0108" Action="Error" />
<Rule Id="CS0109" Action="Error" />

I already have following plugins installed:

  1. Code Analyzer for C#
  2. CodeCracker for C#
like image 432
Vipin Choudhary Avatar asked Mar 31 '17 03:03

Vipin Choudhary


1 Answers

Short answer: there's no supported way of doing this. But you can try to hack around a bit to solve this.

Long answer

There are multiple problems that you would need to solve:

  • The SonarQube Scanner for MsBuild, which you're probably using for pushing the analysis result to the SonarQube server, is pulling down the active rules from the SQ server. This is then being passed to the CoreCompile task in msbuild through the ruleset parameter. So even if you created your own, that would be removed from the parameters and changed to the Sonar one.
  • The end step pushes issues to the SQ server, but the SQ server will ignore any rule ID that is not known. So in your case all CS* issues will be ignored.

At the moment I don't think there's an easy solution to these problems. The general suggestion would be to create your SQ plugin, which defines all CS* rules. Get these rules into the ruleset file (probably between the begin and build phase), parse the output json file and send the results to the server. This would work, but it's a pretty big task, and there are many places where this can go haywire.

Another approach is to have a look at the SonarQube Roslyn SDK. This SDK let's you create a SonarQube plugin from Roslyn nuget analyzers. If you create such a plugin, you'll see that it has 2-3 XML files embedded. These files describe the rules of the plugin. To support your case I would:

  • Create a Roslyn analyzer package with one rule. (Which doesn't report any issues.)
  • Change the embedded files to define the CS* rules. It's probably not that easy to get hold of a list of all CS* rules, but this could be a good start.
  • Deploy the SQ plugin to the SQ server, and hope that it works.
like image 182
Tamas Avatar answered Oct 13 '22 19:10

Tamas