1

I'm currently having an issue getting StyleCop.Analyzers to work with SonarQube. I'm using v6.7 of SonarQube, and I've tried this with multiple versions of the SonarC# plugin.

The recommended way to get the custom rules into SonarQube seems to be to use the SonarQube Roslyn SDK tool (https://github.com/SonarSource/sonarqube-roslyn-sdk) to generate a plugin from a Roslyn analyzer, in this case the StyleCop.Analyers NuGet package.

This seemed to work OK for both v1.0.0 and v1.1.0-beta of the package, and the rules show up in SonarQube for both - however using the latest version of SonarC# the project won't be scanned properly, and the number of C# lines of code & issues found is 0. However if you downgrade to v5.11 of the plugin, the project is scanned properly, it finds the ~2k lines of code, and any StyleCop warnings are shown properly as far as I can tell.

In the VSTS build it looks as though the plugin is working, because the StyleCop warnings do appear in the MSBuild stage (my understanding is that the SonarQube rules override any code analysis rules in the build), but they don't show at all in the summary on the project page in SonarQube.

The SQ Roslyn SDK project says it's compatible with v4.5 or higher of the C# plugin - but it doesn't look like it's being actively maintained.

I can't see any errors in the SonarQube logs, but there are a few warnings in the "Complete SonarQube analysis" task in VSTS:

2018-01-03T15:07:50.0734421Z WARNING: WARN: Protobuf file not found: null\output-cs\encoding.pb
2018-01-03T15:07:50.0734783Z WARNING: WARN: Protobuf file not found: null\output-cs\metrics.pb
2018-01-03T15:07:50.0735152Z WARNING: WARN: Protobuf file not found: null\output-cs\issues.pb
2018-01-03T15:07:50.0735516Z WARNING: WARN: Protobuf file not found: null\output-cs\token-type.pb
2018-01-03T15:07:50.0735888Z WARNING: WARN: Protobuf file not found: null\output-cs\symrefs.pb
2018-01-03T15:07:50.0736289Z WARNING: WARN: Protobuf file not found: null\output-cs\token-cpd.pb

Not really sure if this is an issue with the C# plugin or the SDK tool - has anyone else had any similar issues? Are there any workarounds other than using an older version of the C# plugin?

G. Ann - SonarSource Team
  • 22,346
  • 4
  • 40
  • 76
Tom Anderson
  • 99
  • 11
  • Have a look [here](https://github.com/SonarSource/sonar-csharp/issues/492), It looks like an old issue is returned. – Jeroen Heier Jan 04 '18 at 05:10

1 Answers1

2

The SonarQube Roslyn SDK tool is still the recommended way to connect third-party Roslyn analysers to SonarQube. There hasn't been any need to change the SDK recently as the way the generated plugins are handled by the SonarC# plugin has not changed.

I've just tried generating a new plugin for StyleCop, configured the Quality Profile, assigned it to project etc and the analysis worked as expected and uploaded StyleCop issues to SonarQube. I was using the following versions (although I was running the analysis locally rather than using VSTS): SonarQube 6.7; Scanner for MSBuild v4.0.0.821; C# plugin v6.7; StyleCop 1.0

I think I can explain why the issues appear when you are using v5.11 of the SonarC# plugin but not later versions. v5.11 was the last version had the ability to run the Roslyn analysers itself (the SonarC# plugin had its own exe that would open the C# files, run the Roslyn analyzers against them, and upload the issues). This feature enabled Roslyn analyzers to be used even when using MSBuild v12, which doesn't support running Roslyn analyzers as part of the build. Support for that feature was dropped in version 6.0 of the SonarC# plugin (https://github.com/SonarSource/sonar-csharp/releases/tag/6.0.0.2033).

My guess is that the issue is not with the SDK or the StyleCop plugin. Are you seeing any issues generated by the SonarC# analyzer itself, or any code metrics? If not, then it's likely a more general problem with the build, rather than something specific to the SDK/StyleCop.

Some other suggestions: * are you using the most recent version of the SonarQube extension for VSTS?

  • does it work correctly if you run the analysis from the line using the Scanner for MSBuild directly?

  • try increasing the log level of the SonarQube tasks by setting /d:sonar.verbose=true in the "Advanced/Additional Settings" section of the Begin task.

  • the output you are describing is consistent with the End step not being able to find the issues files and protobuf files that were created during the build. If you are using a non-hosted build agent, you could try looking at the sonar-project.properties file that is generated by the End task (it will be in the .sonarqube\out folder for the build). Check that the file contains references to *.RoslynCA.json files and that those files exist and contain the expected Roslyn issues. The file should also contain *.sonar.cs.analyzer.projectOutPath entries that point to folders on disc. The protobuf files should be in a subfolder called "output-cs".

  • finally, you could check for warnings in the MSBuild output as described in https://groups.google.com/forum/#!topic/sonarqube/11YITqrltIk.

duncanp
  • 1,572
  • 1
  • 10
  • 8
  • Thanks for this - I haven't been able to completely resolve this, but this was very helpful for troubleshooting. I'm also not able to test v4 of the Scanner, since I'm only using the VSTS task, which seems to use v3. So far, StyleCop does work if used alongside the SonarC# rules (e.g. if you use Sonar Way as a parent profile) but if you disable ALL the SonarC# rules in the profile, it still finds issues, but just won't display the number of lines of code, or the number of duplications. – Tom Anderson Jan 05 '18 at 10:15