Azure DevOps C# Error loading external issues into SonarCloud

SonarQube Cloud
, , , ,
6

The default mechanism worked for me using that analyzer and the SonarScanner for MSBuild: see here.

My sample solution is in the attached zip.
ThirdPartyRoslynIssues.zip (1.3 KB)

Debugging:
Debugging what is happening on a CI build agent is easier if you have access to the build agent machine so you can look at the files that are produced during the build. If you don’t, here are some things you can check without access to the machine:

  1. check that issues from the SonarC# analyzer are being reported correctly. If necessary, create a new issue in the code - just adding // TODO will trigger S1135 which should be on by default.
    If “normal” SonarC# issues are being reported then the basic end-to-end process is working correctly.
  2. check for any warnings in the CI build output log
  3. also in the CI build output log, check the parameters passed to csc.exe. They should include the csharpguidelinesanalyzer dll, passed as an /analyzer.
    If it doesn’t, then check your project is correctly configured to include the analyzer as a NuGet package.

If you do have access to the build machine, have a look in the Roslyn error log files to see if they contain the issues you expect. You can find the names and locations of the error log files by looking at the arguments to csc.exe. They will look something like the following:
/errorlog:D:\a\1\s\src\Core\bin\Release\net46\SonarLint.VisualStudio.Core.dll.RoslynCA.json

If you don’t have access to the build machine you can add build steps to find and publish those ‘.json’ files so you can look at them. Another alternative is to run the analysis locally on your own machine using the SonarScanner for MSBuild. The RoslynCS.json files will be produce as part of the MSBuild phase.

The Roslyn error log from my test is here: ThirdPartyRoslynIssues.dll.RoslynCA.json (7.6 KB)

One thing I noticed is that the issue for “AV2210 - Build with -warnaserror” was not uploaded. My guess is that this is because it does not have any information about the location of the issue. However, in that case I would have expected it to be reported as a Sonar project-level issue.