Sonarqube-roslyn-sdk deprecation

[Andrei_Epure]

Hello @peterw . First of all, please accept my apologies for the late answer.

@peterw

Do you have an update for this sdk yet? It hasn’t had a new release for over 2 years now, its getting out of date with the latest Visual Studio changes, for example these:

My colleague @duncanp gave an extensive reply here, I will quote it:

@duncanp

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.

@peterw

And as far as I can tell SonarQube also doesn’t support the EditorConfig configuration files for Rosyln analysers.

We use EditorConfig to configure StyleCopAnalyzers in our sonar-dotnet project, and we import SA issues in our SonarCloud project - so if you want to import results for third party analyzers, using editorconfig is the way to go.