sonar-dotnet holds both the Roslyn analyzers and the SonarQube plugin

One repository, two products

The repository description calls it a code analyzer for C# and VB.NET projects, and the README is more precise about what is inside. The README states that this repository contains the source for the Roslyn analyzers and the Java plugin that integrates .NET analysis with SonarQube. Those are two different products with two different deployment models. The Roslyn analyzers are the part that runs on your machine. They are published to NuGet.org as SonarAnalyzer.CSharp and SonarAnalyzer.VisualBasic, so they can be referenced from a project file and executed by the compiler, which is what lets findings appear in the IDE while a developer is typing rather than only in a server side report. The Java plugin is the part that runs on the server. It is the integration point that lets a SonarQube Server or SonarQube Cloud instance analyse a .NET project during a scanner run, which is where the project and branch level quality gates live. The repository layout makes the split visible in directory names: sonar-csharp-core, sonar-csharp-plugin, sonar-vbnet-core, sonar-vbnet-plugin and sonar-dotnet-core sit next to an analyzers/ directory, a scripts/ directory, docs/ and a pom.xml for the Java side. The audience is .NET teams and, more specifically, teams already invested in SonarQube. The README also says the analyzers work with SonarQube Server, SonarQube Cloud and SonarQube for IDE, so the same rule set can be used in any of those three.

Rules, metrics, coverage import and third party analyzer results

The feature list is where the scope becomes concrete. The rule count is stated as 480+ C# rules and 210+ VB.NET rules. Those rules inspect code for bugs, vulnerabilities and maintainability issues, which are the three categories the README names. Beyond rules, the analyzers compute metrics, and the README lists cognitive complexity, duplications and number of lines among them. Cognitive complexity in particular is a measure that penalises deeply nested control flow rather than raw length, which is why it appears in a maintainability bucket rather than a style one. Coverage import is a separate capability and covers five tools: Visual Studio Code Coverage, dotCover, OpenCover, Coverlet and Altcover. The README links to the community article about importing coverage reports, and separately to the article on SonarQube and code coverage. That import path is what lets an existing .NET test setup contribute coverage numbers without replacing the test runner. Third party Roslyn analyzer results can also be imported, which matters because most .NET code bases already run StyleCop, Roslynator or similar, and having two sets of findings in one report is better than having them in two. Finally there is support for custom rules, with a link to the sonarqube-roslyn-sdk repository. The README also tells you that if you have an idea for a rule but are not sure that everyone needs it, you can implement your own Roslyn analyzer, and it points at a Microsoft tutorial to start from.

The same rules for developer written and AI generated code

One sentence in the README carries more weight than the rest of the marketing copy. The analyzers apply the same rules to developer-written and AI-generated code, giving teams a consistent way to verify code before it reaches production. That is a deliberate position rather than a slogan. A code base where a quarter of the commits come from a coding assistant is a code base where the review boundary has to be explicit, and the answer cannot be that machine written code is exempt. If the same rule set applies to both, then the question of how a line was produced stops mattering, and the review becomes about the code. The second half of that sentence is the operational part. Verifying before production is exactly what the plugin does, since SonarQube runs the analysis as part of the build pipeline and the quality gate decides whether the build is allowed to continue. The README is also clear that rule requests go through a process. To request new rules you contact the team on the Community Forum, and the pull request guidance suggests avoiding the implementation of new rules, as a specification process is required first. That is a reasonable policy for a rule set that hundreds of teams depend on, because a rule that changes what a build fails on is an API change in practice.

Running it: IDE, build and server

There are three ways to meet the analyzers, and the difference is where the feedback lands. In the IDE, the analyzers run as Roslyn analyzers and surface findings while the developer works. The README describes the outcome as findings surfacing while developers work in their IDE, and points to SonarQube for IDE as one of the three products the analyzers work with. During a build, the analyzers run as part of the compilation through SonarScanner for .NET, which is the path the README links under the heading Analyze projects with SonarScanner for .NET. On the server, the Java plugin integrates the results into SonarQube Server or SonarQube Cloud, where the quality gate is evaluated. The README carries badges for both an Analyzer project and a Plugin project on SonarCloud, each with a quality gate badge and a coverage badge, which is a neat illustration that the two halves are tracked separately. The public resources section adds the issue tracking document at docs/issues.md and the project homepage at redirect.sonarsource.com/plugins/csharp.html. For feedback there are two channels. The Community Forum at community.sonarsource.com is for feedback, help and requests for new rules or features, while GitHub issues are for bugs, false positives and false negatives. That split matters in practice, because a false positive report and a request for a new rule are different kinds of work and go to different places.

Contributing: the CI runs on demand, not on the pull request

The contributing section is unusually concrete, and one detail will matter if you plan to send a pull request. CI does not get automatically triggered on pull requests from external contributors. A member of the team reviews the code and triggers the CI on demand by adding a comment on the pull request.

/azp run Sonar.Net

That comment runs the full pipeline, including plugin tests and promotion. The pipeline itself is Azure Pipelines, and the README carries a build status badge pointing at the Sonar.Net project on dev.azure.com with the master branch. Before submitting, the guidance asks you to make sure that all tests are passing, all checks must be green, and to follow the project's coding style. There are also dedicated documents in the repository for building, testing and debugging the .NET analyzer and for the Java plugin, plus one on how to re-generate the NuGet lock files. There is a Contributor License Agreement. If you did not sign it in the past, you are asked to let the team know in the pull request using your user handle from the Community Forum, and they arrange the signing via a private message. The repository also has an .editorconfig, a .globalconfig and a global.json, which together pin formatting, analyzer severity settings and the SDK version used by the build.

The licence question is not settled by the badge alone

This is the part to read carefully, and there is a visible tension in the repository. The README carries a licence badge that reads SSALv1, which is the Sonar Source Available Licence, and the repository entries include both a LICENSE.txt and a NOTICE.txt. The licence field on the repository says Other, with the note that it is a custom licence GitHub cannot classify and that the LICENSE file holds the terms. That is a meaningful difference from a permissive open source licence. A source available licence generally restricts redistribution and competing use, and it is not the same thing as the MIT or Apache 2 terms that most open source .NET tooling ships under. If your plan involves shipping the analyzer inside a commercial product or offering it as a service, read LICENSE.txt carefully and take the restriction seriously. The project also carries a SECURITY.md file and a NOTICE.txt, which is where third party attributions live. On activity, the picture is healthy. The last push was on 2026-10-20, the repository is not archived, and the releases are 10.35.0.4138 from 2026-09-28, 10.34.0.3385 from 2026-09-09 and 10.33.0.1635 from 2026-08-21. The four part version numbers are the SonarQube plugin versioning scheme, where the third and fourth components track the analyser and the plugin build, and the monthly cadence means a new plugin release lands roughly once a month. The .mcp.json file at the root of the tree is also worth noting. It is the configuration file for Model Context Protocol servers, which suggests the project has prepared for AI assisted contributions.

Editorial conclusion

Adopt sonar-dotnet if your team writes C# or VB.NET and wants the same findings in the IDE, in the build and in SonarQube, and verify first which licence terms apply to your use, since the badge points at the SSALv1 while the repository licence field records a custom licence GitHub cannot classify. Do not adopt it as a general code quality tool outside the Sonar ecosystem. Before adding a rule, read the contribution guidance, because the project asks that new rule implementations go through a specification process first.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. SonarSource/sonar-dotnet on GitHub