3 years ago we integrated our Roslyn Analyzers into SonarQube 7.3 by using the SonarQube Roslyn SDK. We created the Plugins using the 2.6.2 Version of the corresponding Nuget Packages. We created a C# Ruleset in SonarQube that SonarLint used in VS. We integrated SonarQube into our DevOps CI/CD Piplines using the SonarQube Extension. Sofar everthing worked fine.
Over Time we upgraded to newer .NET Versions and the Analyzer Results on SonarQube differed from the SonarLint outputs more and more.
Now we upgraded to VS 2019 and got the following SonarLint errors:
ERROR: Could not find compatible implementation of ‘IGetTaintVulnerabilitiesRequest’ for SonarQube 7.3.0.15553.
So we upgraded our SonarQube to 7.9.6 but the error still exists.
We also wanted to Upgrade the Roslyn Plugins using the SonarQube Roslyn SDK but the Generator does not accept the newest Roslyn Analyzer Packages. Is the SonarQube Roslyn SDK deprecated.
I am missing a clear procedure of how to integrate and maintain the following Components:
That’s a lot of questions, so it’s difficult to know where to start. Please have a look at the community FAQ which suggests keeping to one subject per thread. The title of your post is about using third-party Roslyn analyzers, so I’ll focus on that and give brief answers to some of the others. If you have follow up questions please consider splitting them out to separate posts. It will make it much easier to keep track of which points are still open.
SonarQube Roslyn SDK
Originally, this was the only way to integrate third-party Roslyn analyzers with SonarQube, and required extra work on the part of the end-user to generate and install a custom SonarQube plugin.
The SonarScanner for .NET now supports importing issues from third-party Roslyn analyzers out of the box. See the Notes on external .NET issues section in the docs for more information.
This approach has a few pros and cons compare to the SonarQube Roslyn SDK. On the plus-side, it doesn’t require any extra steps to make it work, and it is supported on both SonarQube and SonarCloud. On the down-side, you can’t configure the rules to run in a Quality Profile, and you can’t change the status of reported issues in SonarQube.
The SonarQube Roslyn SDK has been somewhat neglected since we add the out of the box support for importing issues, and we’ve been discussing internally what to do with it going forwards.
Our current thinking is that we will do some work on the SDK after the next SonarQube LTS has been released to tidy up the code and make sure it works with the LTS and the latest version of Roslyn. We’ll then look to move the ownership of the SDK to the community.
Error in the IDE
This just means that SonarLint is trying to use feature that isn’t available in your version of SonarQube. We’ve improved the message displayed in the IDE (see SLVS #2179) in the latest version of SonarLint.
Miscellaneous
SonarQube: you have two choices - either stay on the LTS version, or install each new post-LTS update as it is released.
SonarLint : we recommend staying on the latest version, which will contain the latest analysis rules and any new features.
Azure Dev Ops extension: most releases are just minor version updates, which means that your Azure Pipelines will automatically pick up the new version. If we do release a major version update then the way Azure Pipeline versioning works means you will need to manually change your pipeline to use the new major version. If we do change the major version number it will normally because there is a breaking change so check the release notes for the extension before upgrading.
C# plugins: if you mean the Sonar C# language plugin then this is no longer an issue; in the newer versions of SonarQube the built-in language plugins can no longer be upgraded independently.
VS2019: the official VS support policy is here. FYI we do our pre-release testing of SonarLint on the latest released VS2019 version.