Roslynator: C# Analysis Tools That Split Across IDE, NuGet and CLI

What Roslynator solves, and who it is actually for

Roslynator is a set of code analysis tools for C#, powered by Roslyn. That one line hides the useful part: it is not a single product but a family of deliverables aimed at different people. Application developers get IDE extensions for Visual Studio 2026, Visual Studio 2022 and VS Code, plus NuGet packages that carry the analyzers. Analyzer authors get a testing framework for unit-testing analyzers, refactorings and code fixes, and client libraries that extend the Roslyn API.

The README states plainly that analyzers are not included in the Roslynator IDE extensions, and that you should use the Roslynator NuGet packages for diagnostics. That single sentence is the most consequential fact on the page. If you install the extension expecting warnings to appear in your build, you will see refactorings and compiler diagnostic fixes but no analyzer diagnostics. The extension and the package are complementary, not interchangeable.

The audience is therefore split three ways. Teams that want build-time enforcement install packages. Developers who want quick refactorings install an extension. People building their own analyzers use the testing framework and the client libraries, which the README says do not include analyzers or refactorings themselves.

How the pieces fit: IDE extension, NuGet analyzer, CLI

The architecture follows Roslyn's own split. Analyzers are ordinary Roslyn analyzers delivered as NuGet packages, so they run wherever the compiler runs: in the IDE, in dotnet build, and in CI. The IDE extensions are separate artifacts that provide refactorings and fixes for compiler diagnostics, and they deliberately omit the analyzers.

Three analyzer packages are listed: Roslynator.Analyzers, Roslynator.CodeAnalysis.Analyzers and Roslynator.Formatting.Analyzers. The names suggest the division of labour, with one package focused on formatting rules and one on Roslyn API usage, though the README does not spell out the rule count or the contents of each package.

The client libraries form a second layer, and the README is explicit that they are for building custom analyzers and refactorings rather than for consuming existing ones. Roslynator.Core extends Microsoft.CodeAnalysis.Common, Roslynator.Workspaces.Core extends Microsoft.CodeAnalysis.Workspaces.Common, Roslynator.CSharp extends Microsoft.CodeAnalysis.CSharp, and Roslynator.CSharp.Workspaces extends Microsoft.CodeAnalysis.CSharp.Workspaces. That mapping matters if you are writing tooling: you pick the library that matches the Roslyn layer you already depend on, instead of pulling in a broader package.

Installing Roslynator analyzers and the CLI

The README gives exactly one install command, and it is for the command line tool:

dotnet tool install -g roslynator.dotnet.cli

That installs the Roslynator CLI as a global .NET tool. After it completes, the tool is available on your path; the README points to the CLI documentation for usage rather than listing subcommands inline, so check that page before scripting anything.

For analyzer diagnostics in a project, the README directs you to the NuGet packages instead of the extensions, naming Roslynator.Analyzers, Roslynator.CodeAnalysis.Analyzers and Roslynator.Formatting.Analyzers. Adding one of those packages to a project is the mechanism, and the README does not document severity configuration on the front page; it links to a separate configuration page, which is where rule IDs and severities would be set.

If you prefer an editor extension, the Visual Studio 2026 and VS Code extensions are the current ones, and the README notes that the VS Code extension requires legacy OmniSharp via `dotnet.server.useOmnisharp` set to `true`. With C# Dev Kit, the README says to use the NuGet packages instead. That is a real constraint, not a footnote: on a modern VS Code setup the extension may simply not be the right route.

Where Roslynator stops being the right tool

The clearest limitation is the version split on Visual Studio 2022. The README describes the Visual Studio 2022 extension as the last 4.x release and tells you to pin it or use the NuGet packages. If your team is standardised on VS 2022 and expects the extension to track current development, that expectation is wrong. The 5.0.0 release exists, but the README ties the 2022 extension to the 4.x line.

The second limitation is the VS Code path. Requiring the legacy OmniSharp setting is a compatibility constraint that cuts against the direction most C# editor setups have moved. The README's own advice, to use NuGet packages when C# Dev Kit is present, means the extension is not the answer for those users.

The third is scope. Roslynator analyses C#. It is not a general .NET tool that inspects project files, package graphs or MSBuild targets. If your problem is dependency hygiene or build configuration, analyzers that reason about C# syntax and semantics are the wrong instrument.

Finally, the README does not document rollback, an uninstall procedure, or how analyzer rules interact with an existing ruleset. Those gaps matter during adoption, and the configuration page is the place to look rather than the front page.

Roslynator compared with ReSharper

The comparison people search for is Roslynator versus ReSharper, and the difference is architectural rather than a matter of rule counts. ReSharper is a commercial IDE product with its own analysis engine; Roslynator is built on Roslyn and distributed through the channels Roslyn already provides. That means Roslynator analyzers run in the build, in CI, and in any editor that loads Roslyn analyzers, because they are NuGet packages. A product installed into a specific IDE does not travel that way.

The practical consequence is where enforcement happens. With Roslynator, the same analyzer package that warns you in the editor can fail a build on a server. The trade-off is that you assemble the experience yourself: extension here, package there, CLI in the pipeline. ReSharper-style tooling tends to arrive as one integrated install, which is simpler but does not put the rules into the compiler.

The README also notes that the Roslynator CLI is integrated in MegaLinter, an open-source linter aggregator for CI. That is a second route into a pipeline if you already run MegaLinter and would rather not wire the CLI up yourself.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-13. The most recent release listed is v5.0.0 from 2026-08-21, preceded by v4.16.1 and v4.16.0 in August 2026. The project is supported by the .NET Foundation and has adopted the Contributor Covenant code of conduct.

The upgrade cost is concentrated in the Visual Studio 2022 situation. The README's instruction to pin the 4.x extension or move to NuGet packages means a version decision, not just an update. Because analyzers ship as packages, the package version is the thing your build depends on, and it can move independently of whichever extension a developer has installed.

On licensing, the repository metadata reports the licence as NOASSERTION, which means the automated classifier could not map the LICENSE.txt file to a known SPDX identifier. The README does not state licence terms. Read LICENSE.txt and NOTICE.md directly before you depend on the project commercially; nothing here should be read as legal advice.

Contributions are documented through a developer guide, a page on contributing with agent skills, and an up-for-grabs issue label. The README notes that agent skills live in .claude/skills/ with workflows for Cursor and Claude Code, and that larger tasks such as adding a new analyzer or refactoring should be discussed first.

Editorial conclusion

Adopt Roslynator if you want C# analyzers that install as ordinary NuGet packages and a CLI that runs in CI, and if your team can live with the split between the IDE extension and the analyzer packages. Do not adopt it expecting one install to cover everything: the IDE extensions do not include analyzers. Before rolling it out, verify which Visual Studio version you are on, since the 2022 extension is described as the last 4.x release, and check whether your editor uses the legacy OmniSharp setting or C# Dev Kit.

Frequently asked questions

Official sources

1. dotnet/roslynator on GitHub
2. Issues
3. Project website
4. README
5. Releases