dotnet/roslyn: the C# and Visual Basic compiler you can call from your own code

What Roslyn actually is, and who ends up depending on it

The README describes Roslyn as "the open-source implementation of both the C# and Visual Basic compilers with an API surface for building code analysis tools." That sentence carries two products in one repository. The first is the compiler that turns your source into assemblies. The second is the set of APIs that expose the compiler's own view of your code: syntax trees, symbols, semantic models, and diagnostics.

That second product is the reason most people arrive here. If you are writing a source generator, a custom analyzer, a migration tool, a code formatter, or an editor integration for C#, you are consuming Roslyn whether or not you clone this repository. The repository itself is the place where the compiler and those APIs are built.

It is not aimed at the developer who simply wants warnings in an editor. Those warnings reach you through the .NET SDK and through Visual Studio, which consume Roslyn internally. The audience for this repository is narrower: people building tooling, and people fixing the compiler itself.

The compiler API model: syntax trees, symbols and diagnostics

The architecture is documented in the Roslyn Architecture Overview, linked from the README as the starting point for the APIs. The model it describes separates the compiler into layers that a tool can query independently.

The compiler front end parses source text into syntax trees. Above that, a declaration layer binds those trees into symbols, and a semantic model answers questions about what a given node means in context: which overload a call resolves to, what type an expression has, whether a name refers to a local or a field. Diagnostics are produced along the way and can be surfaced to a tool rather than printed to a console.

This layering is what makes Roslyn usable for analysis rather than only for compilation. A tool that only needed to compile code would not need a symbol model exposed at all. The trade-off is that the API surface is large. The README points API suggestions at a separate API review process document in docs/contributing, which tells you the surface is treated as something that changes deliberately rather than freely.

Installing Roslyn and running a first analysis

There is no single install command for Roslyn as a whole. The README does not give one. What it does give is a set of NuGet feeds for pre-release builds, split by component: the compiler feed, the IDE services feed, and the .NET SDK feed. If you are consuming the APIs from your own project, you add the relevant packages through NuGet rather than cloning this repository.

To point a project at the pre-release compiler feed, the README lists this source URL:

dotnet nuget add source https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json

After adding it, a restore will see the pre-release compiler packages published to that feed. The IDE services packages come from a different feed, listed in the README as the vssdk feed, and the .NET SDK packages from a third, listed as the dotnet5 feed. Mixing them up is the most common way to end up with a package that resolves to nothing.

If you are building Roslyn itself rather than consuming it, the repository root carries Build.cmd, build.sh, Restore.cmd, restore.sh, Test.cmd, test.sh, Verify.cmd and verify.sh. The contributing guide linked from the README covers the development workflow, including debugging and running tests on Windows. The README does not document a rollback procedure for a bad pre-release package, so pin versions in your project file if you depend on one.

Where Roslyn is the wrong tool

Roslyn is a compiler with an analysis API, not a linter with a configuration file. If your goal is to enforce a style rule across a codebase, the thing you want is an analyzer package that already implements that rule, not a dependency on the compiler platform itself. Writing an analyzer on top of Roslyn is a real option, but it means owning a tool, not configuring one.

The second limitation is version coupling. The pre-release builds the README advertises are pre-release builds, and the recent release list shows the pattern: v4.2.0-4.22266.5 is labelled .NET 7.0 Preview 5, preceded by .NET 7.0 Preview 2 and Preview 1. A tool built against a pre-release API surface is built against something explicitly labelled as preview. The API review process exists precisely because that surface is expected to move.

The third is scope. Roslyn implements C# and Visual Basic. If your tooling needs another language, the compiler API model does not help you, and the README's own guidance for language feature suggestions points elsewhere, at dotnet/csharplang and dotnet/vblang, rather than at this repository.

Roslyn analyzers versus a standalone parser

The obvious alternative for a tool that needs to understand C# is a standalone parser library that produces a syntax tree and stops there. The difference in approach is the semantic layer. A standalone parser can tell you the shape of an expression; it cannot tell you, without reimplementing binding rules, which method a call resolves to.

Roslyn's design puts that binding inside the compiler, so a tool asks the semantic model instead of reproducing overload resolution. That is the reason source generators and migration tools are written against it. The cost is weight: you take a dependency on the compiler platform, and you inherit its release cadence and its preview labelling.

For a tool that only needs to reformat whitespace or count tokens, the standalone parser is the smaller dependency and the better fit. For anything that needs to know what a name means, the semantic model is the part that is hard to replace, and that is where Roslyn earns its place.

Maintenance, feeds and the licence

The repository is not archived, and the last push was on 2026-09-20. Both core team members and external contributors send pull requests through the same review process, according to the README, and the contributing guide lists separate entry points for IDE bugs, compiler bugs, IDE features and compiler features. The continuous integration tables in the README cover Windows Debug, Windows Release and Unix Debug builds, plus desktop and CoreCLR unit test jobs across x86 and x64.

Upgrade cost is the practical concern. The recent releases are all pre-release builds tied to .NET 7 previews, and the README keeps the compiler, IDE services and .NET SDK feeds separate. A team consuming these packages is tracking a moving target on three feeds at once, and the README does not describe a support window for any of them.

The repository ships License.txt, and the project is under the MIT licence. That is permissive, but this is a description of the licence file, not legal advice; check the terms yourself against how you intend to redistribute.

Editorial conclusion

Adopt Roslyn when you are writing a tool that needs to parse, analyse or generate C# or Visual Basic, and you are ready to track a compiler that moves with the .NET SDK. Do not adopt it as a drop-in replacement for a linter you configure with a file; the repository is a compiler and API surface, not a ruleset. Before committing, verify which NuGet feed carries the build you need, since the README splits compiler, IDE services and .NET SDK packages across three Azure DevOps feeds, and check the API review process document under docs/contributing before you depend on a surface that may still change.

Frequently asked questions

Official sources

1. dotnet/roslyn on GitHub
2. License: MIT
3. Project website
4. README
5. Releases