Sonar scanner for MSBuild is counting word "error" in the file path of "INFO" messages in build step

Hi ,

We have a .net application and when we tried to execute sonarqube analysis from jenkins using Sonar scanner for MSBuild , it failed in the build step . But when we reviewed the jenkins log we found that there is no errors, all are warnings and info messages . But it after build step it is showing there are some error and it failed to complete the static code analysis . When we ran the build command outside sonarqube it completed successfully (0 error) and we found that Sonar scanner for MSBUILD is counting word “error” in the file path of INFO messages . And to fix the issue we disabled the info messages rules in .editorconfig file . After disabling the rule the sonarqube analysis succeeded.

SonarQube version - 8.4.2
Sonar scanner for MSBuild version - 4.10
MSbuild version - 16.9
(Can’t share the code and jenkins log due to organization’s security policy)

Hi @M_K. Thanks for the report.

There are a couple of odd things going on here. The Scanner for MSBuild/.NET doesn’t parse the log output or issue messages, and it shouldn’t fail cause the build step to fail ever if there were critical issues reported.

Also, the scanner generates a ruleset file to configure the Sonar rules, which should take precedence over any settings in an .editorconfig file.

Could you provide some more info to help narrow down the root cause please?

  1. which info messages did you disable?
  2. can you share a suitably redacted example of the line from the log that is causing the problem?
  3. are you running any other analysis rules apart from the Sonar ones?


Hi @duncanp ,

We have disabled the following rules

D:\jenkinslave\workspace\jenkins job name…\Blob for error log\AzBlobCont.cs(line numer ,column number):info MA0038:Make method static[csproj path]

  • we are getting 12 such info messages which contains the word error in the file path and it showing there are 12 errors after build step ( after Sonar scanner MSBuild begin it will execute build step , after build step it throwing there are 12 errors but in actual there is no error in build )

I can see there is a file called . editorconfig file and CodeAnalysis.ruleset inside the project .

Hi @duncanp /Sonarsource team,

I couldn’t find the above mentioned rules in the sonarqube Scanner rule set . Is there any way to add those rules and disable it in the code analysis rule set of sonarqube ?


@M_K those rules are all non-Sonar rules. The CAxxx rules are from Microsoft, and the MAxxx and RCSxxx are external third-party Roslyn analysis rules that are shipped as NuGet packages (Meziantou.Analyzer and Roslynators.Analyzers respectively).

I’m guessing that your projects are referencing those analyzer NuGet packages directly, so the scanner will be attempting to import them as third-party issues as described on this page of the docs (scroll to the section Notes on external .NET issues).

External Roslyn rules are not individually configurable in the SonarQube UI (and the issues raised can’t be individually suppressed either).

However, that doesn’t explain why your build is failing. I created a sample project with code that violated rule MA0038, and was able to analyse it without any problem:


I then added an .editorconfig file that set the rule severity to error:


# MA0038: Make method static
dotnet_diagnostic.MA0038.severity = error

That caused the build to fail:

It is MSBuild/the compiler that is causing the build to fail, not the scanner.

Does your .editorconfig change the severity of any of rules that are causing problems?

There is, but it’s a bit more complicated. You would need to use the SonarQube Roslyn SDK to generate a SonarQube plugin for each external analyzer. You would then be able to enable/disable rules and suppress issues in the SonarQube UI.

Thanks @duncanp for the information.

But have you tried by adding word “error” in the file path where you have violated the rule MA0038 ?

Say for an example , if your file name is abc.cs and the file path is "D:\workspace\error log\abc.cs .
I strongly think that the word “error” in the file path of info messages are causing this issue . (error in folder “error log” counting as an error when the Sonar scanner for MS Build analyse the code ).


Hi @M_K,

I successfully analysed a project with a directory named “error log” from the command line:

It’s possible, but if so it isn’t due to the SonarScanner for .NET.

There are a couple of things you could try to narrow down what is causing the problem:

  1. try to run the analysis with the Scanner from a local developer command prompt. You wouldn’t need to actually run the endstep: running the begin step and the build would be enough.
  • are any issues produced?
  • does the build complete successfully?
  1. try running your Jenkins job without the Scanner begin step, but with Roslyn analysis turned on i.e. by passing -p:RunAnalyzers=true in the MSBuild step (I’m assuming you are referencing the Meziantou.Analyzer package in your projects).
  • are any issues produced?
  • does the build complete successfully?
  1. temporarily rename the directory

Hi @duncanp ,


1- I ran the analysis with scanner from a local command prompt (executed only begin and build step)
•yes it is throwing the same error after build as I got in the jenkins console output ( same issues which was showing in jenkins - issue with info messages having word “error” in the file path )
•Build failed with 12 errors (issue with info messages having word “error” in the file path )

2- ran the job without scanner and added /p:RunAnalyzers=true in the MSBuild step

It didn’t create any issue , build step completed successfully

3- Rename also works .


Hi @M_K,

There are a couple of odd differences in the results we got: it’s weird that building with the scanner fails for you but not for me, and it’s weird that building with /p:RunAnalyzers=true doesn’t report any analysis issues for you. Are you building calling msbuild from the command line, or dotnet build?

Also, you’re using an old version of the scanner from June 2020. Try upgrading to the latest version (v5.4).

Diagnosing the problem without build logs is difficult. Would you be able to share them privately?

This topic was automatically closed after 11 days. New replies are no longer allowed.