Roslynator: C# analyzers and refactorings, from IDE extensions to a CLI

The analyzers and extensions split

The README's first paragraph draws a boundary that catches most newcomers, analyzers are not included in Roslynator IDE extensions, use Roslynator NuGet packages such as Roslynator.Analyzers for diagnostics. The reasoning is architectural, analyzers belong to the compilation and therefore to the build, where NuGet packages enforce rules uniformly across every machine and CI run, while the extensions carry the interactive machinery, refactorings and compiler diagnostic fixes, that only makes sense inside an editor. The three NuGet packages split the diagnostics by concern, Roslynator.Analyzers for the core set, Roslynator.CodeAnalysis.Analyzers for rules about Roslyn analysis code itself, and Roslynator.Formatting.Analyzers for style-level rules. The split also maps to rollout strategy, a team can adopt analyzers gradually through package versions and ruleset configuration while the refactorings arrive with editor updates, the two halves versioning and shipping on their own schedules.

Four delivery surfaces for the interactive tools

The IDE extensions cover the editor matrix. A Visual Studio 2026 extension carries refactorings and compiler diagnostic fixes, with analyzers again via NuGet. The Visual Studio 2022 extension exists as the last 4.x release, with the advice to pin it or use NuGet packages, marking where the 5.x line's support boundary sits. A VS Code extension on the marketplace and Open VSX brings the same refactorings and fixes to the cross-platform editor, with one requirement spelled out, it requires legacy OmniSharp with dotnet.server.useOmnisharp set to true, and teams using C# Dev Kit should use the NuGet packages instead, since the Dev Kit's language server cannot host these extensions. The Open VSX listing extends the same extension to VSCodium and other editors that use that marketplace, so the VS Code surface is not tied to Microsoft's registry alone.

The CLI and MegaLinter

For CI, the command line tool installs as a global dotnet tool:

dotnet tool install -g roslynator.dotnet.cli

with its own documentation section covering the commands. The CLI is also integrated in MegaLinter, the open-source linter aggregator, with a Roslynator descriptor page, meaning a CI pipeline that already runs MegaLinter gains Roslynator's checks through configuration rather than a separate install step. The CLI carries the refactorings and fixes into scripted contexts, the batch form of what the IDE extensions do interactively, and combined with the NuGet analyzers it closes the loop, diagnostics in the build, fixes available in the editor or the pipeline.

A testing framework for analyzer authors

The testing framework exists to unit-test analyzers, refactorings and code fixes, the artifacts this project itself produces and the artifacts any team writing custom Roslyn tooling produces. Its presence signals the project's dual nature, a tool set and a reference implementation of Roslyn tooling practice, and the testing documentation covers the verification patterns. For teams writing their own analyzers, the framework answers the hardest question in the space, how to assert on compiler diagnostics and code fixes deterministically, by providing the harness rather than leaving each team to build one from raw Roslyn testing APIs.

Client libraries that extend Roslyn

Four client libraries extend the Roslyn API and are intended for building custom analyzers and refactorings, with the explicit note that these packages do not include analyzers or refactorings themselves. The table maps each to its Microsoft.CodeAnalysis foundation, Roslynator.Core over CodeAnalysis.Common, Roslynator.Workspaces.Core over Workspaces.Common, Roslynator.CSharp over CSharp, and Roslynator.CSharp.Workspaces over CSharp.Workspaces. The layering lets a custom tool take only the depth it needs, core utilities without workspace services, or the CSharp workspace stack for full refactoring support, and the API reference on the documentation site covers the surface these packages add.

Contribution through agent skills

The contribution section reflects the current era of tooling directly. Agent skills in the .claude/skills directory provide step-by-step workflows for Cursor and Claude Code covering adding analyzers, refactorings, compiler fixes and bug fixes, and the SKILL.md files can be read directly as contributor guides, with CONTRIBUTING.md beside them. The triage advice is practical, bugfixes and small improvements can be implemented right away, while larger tasks such as adding a new analyzer or refactoring should be discussed first. The .cursor and .claude directories at the repository root carry the configurations, and an up-for-grabs issue label filters the entry points, the pair that lowers the barrier to a codebase whose domain is the C# compiler API itself. The GitVersion.yml at the root marks the automated versioning scheme the releases follow, consistent with the numbered tags the NuGet packages and extensions share.

Under the dotnet organization, funded openly

The project's move under the dotnet GitHub organization is stated through its support, it is supported by the .NET Foundation, has adopted the Contributor Covenant code of conduct, and its donations section publishes named amounts, the .NET on AWS Open Source Software Fund donating 6000 dollars at 500 monthly from November 2024, Microsoft donating 1000 dollars, and three individual monthly sponsors listed with their start dates and amounts. Release activity is steady, v4.16.0 and v4.16.1 in August 2026 closing the 4.x line before v5.0.0 on 2026-08-21, with the main branch pushed 2026-09-13. The documentation lives at josefpihrt.github.io, the original author's GitHub Pages, carrying configuration, guides, CLI, testing and API reference sections.

Editorial conclusion

Use Roslynator when C# code needs additional diagnostics, refactorings and compiler diagnostic fixes beyond what the compiler ships, choosing the delivery per context, IDE extensions for interactive work, NuGet analyzer packages for build-time enforcement, and the CLI or MegaLinter for CI. Note the split the README insists on, the IDE extensions do not include analyzers, which come from NuGet. Before adopting, check the editor requirements, the VS Code extension needs legacy OmniSharp while C# Dev Kit users should take the NuGet route, pin Visual Studio 2022 users to the last 4.x release, and read the configuration docs before enabling analyzers at scale.

Frequently asked questions

Official sources

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