Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

251
Visualizações
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#
about 4 years ago · Santiago Trujillo
1 Respostas
Responde à pergunta

0

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.
about 4 years ago · Santiago Trujillo Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda