DiagnosticCatalog.Roslyn 1.0.0

DiagnosticCatalog.Roslyn

🌍 Languages:
🇬🇧 English (this file) | 🇫🇷 Français

The Roslyn analyzer-authoring rules (RS1xxx, RS2xxx) as strongly referenced constants, so that SuppressMessageAttribute takes compile-checked references instead of magic strings.

🪞 Mirrors Microsoft.CodeAnalysis.Analyzers 5.6.0

52 rules, 9 categories, every identifier and category read from that release's own analyzers. Regenerated 2026-08-05.

Unofficial. Not affiliated with, endorsed by, or supported by Microsoft.

Why

Nine categories, and two of them break the pattern the other seven follow.

Seven read MicrosoftCodeAnalysis followed by a word: MicrosoftCodeAnalysisCorrectness, MicrosoftCodeAnalysisDesign, MicrosoftCodeAnalysisReleaseTracking. Nobody types those from memory, but at least they are guessable once you have seen one.

Then there is this:

The same concept, correctness, spelled two ways in one package — twenty rules under the long form and three under the short one, with nothing to tell you which is which. Library is a category with exactly one rule in it.

[SuppressMessage("MicrosoftCodeAnalysisCorrectness", "RS1016:...", Justification = "…")]   // wrong, and silent

Get the id wrong and the suppression silently does nothing — the warning simply stays. Get the category wrong and nothing happens at all, ever: the .NET platform never reads that argument, so no error, no warning and no failing test will tell you.

using DiagnosticCatalog.Roslyn;

[SuppressMessage(
    RoslynRule.RS1016.Category,
    RoslynRule.RS1016.Id,
    Justification = "The fixer is deliberately single-document; FixAll would be wrong here.")]

Who runs these without asking

Microsoft.CodeAnalysis.Analyzers reaches a project transitively, through Microsoft.CodeAnalysis.CSharp. Reference the Roslyn APIs to write an analyzer, a code fix, a source generator or an analyzer test, and these fifty-two rules come with them — the same shape as xUnit's and MSTest's analyzers arriving with their test frameworks.

Installation

<PackageReference Include="DiagnosticCatalog.Roslyn" Version="1.0.0" />

That is the only reference you need. This package depends on DiagnosticCatalog, which carries the DCAT analyzers and code fixes beside its attributes, so referencing this catalogue is what switches on the checks that validate rule declarations and their use sites. The assembly doing the reporting is called DiagnosticCatalog.Analyzers.dll, and despite the similar name it is a different thing entirely: it raises this library's own DCAT diagnostics, never Roslyn's RS ones, which are what this catalogue names.

What is in the package

52 rules across 9 categories. Thirteen carry a help link; the rest declare none.

[DiagnosticRule]
public static class RS1016
{
    public const string Id = nameof(RS1016);
    public const string Category = RoslynCategory.Correctness;
}

Not the RS00xx rules

Three Microsoft packages issue RS rules, and this catalogue holds one of them:

The ids partition cleanly, so there is no ambiguity about which rule lives where. The reason the other two were absent for a while was the icon: three catalogues of RS rules would all have wanted the same two letters, and no icon could tell them apart. That is settled — a badge whose prefix is already in service names the catalogue's subject instead, and RS stays here (ADR-0035). Merging them into one catalogue still has no shape in the manifest, which takes one package per catalogue. That is a decision somebody has to make before those 26 rules can be catalogued at all; this package does not pretend to have made it.

Categories declared once

RoslynCategory holds each category once, and the rules reference it — so a category's spelling exists in exactly one place, which for MicrosoftCodeAnalysisReleaseTracking is worth more than usual. It is internal by design: a suppression reaches a category through the rule that carries it, RoslynRule.RS1016.Category, and never through the category constant on its own. The two fold to the same string today and stop agreeing the day a rule moves (ADR-0026).

Limits

[SuppressMessage] cannot suppress compiler warnings — CS0219 and friends need #pragma warning disable, which takes bare identifiers and so can never reference a constant.

That limit bites harder here than elsewhere, and it is worth being straight about. Several RS rules are reported against a whole assembly or a project file rather than a syntax node — RS1036 Specify EnforceExtendedAnalyzerRules, RS1038 Compiler extensions should target netstandard2.0, RS2008 Enable analyzer release tracking — and the usual answer to those is #pragma or an .editorconfig entry, neither of which can take a constant. This repository silences three of them that way in its own tests. Where [SuppressMessage] does apply, the constants here work; where it does not, no catalogue can help.

How it is produced

Not transcribed from documentation. The generator reads the analyzer assemblies' metadata for the types they mark with [DiagnosticAnalyzer], constructs those, and reads the DiagnosticDescriptor instances they actually declare — the only source that cannot have drifted, which is what surfaced the two off-pattern categories above.

dotnet run --project src/DiagnosticCatalog.Cli -- generate \
    --package Microsoft.CodeAnalysis.Analyzers --package-version latest \
    --namespace DiagnosticCatalog.Roslyn --container RoslynRule \
    --output src/DiagnosticCatalog.Roslyn/RoslynRules.g.cs

How it stays current

A nightly workflow regenerates every catalogue from its upstream package and opens a pull request when anything the catalogue publishes has moved. It never publishes: a category or an id that changed upstream changes a published contract, and since the platform never reads a suppression's category, a wrong value merged unreviewed would produce no symptom anywhere. A human reads the diff.

A rule retired upstream is never deleted. It is kept and marked [Obsolete] naming the version that dropped it, so a project still referencing it gets a CS0618 warning telling it to remove the suppression — rather than a hard error from a member that vanished. Consumers inline constant values at their own compile time, so deleting one breaks their recompilation.

How it reaches nuget.org

This catalogue rides the roslyn release train and versions independently of the foundation, so it can follow Microsoft.CodeAnalysis.Analyzers' releases without dragging anything else along.

Publishing is not part of the nightly. A maintainer pushes a roslyn-vX.Y.Z tag, and the release workflow packs the package, embeds an SPDX SBOM, and publishes through NuGet Trusted Publishing with signed build provenance — no long-lived API key exists anywhere to leak.

See also

Every catalogue this repository publishes is listed in one place — pick the one that matches an analyzer you run:

The ready-made catalogues

Want a catalogue of your own? Your analyzer's rules, or an internal ruleset, are declared exactly the way these are: a static class of constants marked [DiagnosticRule], referenced by consumers instead of retyped. That marker ships in DiagnosticCatalog, the foundation this catalogue is built on, and its README is the guide.

Documentation

For using a catalogue, in the order the work happens:

• Getting started — ten minutes: reference this package, rewrite one suppression, break it on purpose and watch the compiler catch it.
• Writing suppressions that the compiler checks — the full version, including migrating the literals you already have.
• Publishing a catalogue — the structural contract, and how to ship one for your own analyzer's rules.
• Configuration — every severity key, the category-wide switch, and the PrivateAssets mistake that silences everything.
• Troubleshooting — by symptom: nothing is reported, CS0117, CS0618 after an upgrade.

The documentation map picks a page by what you are trying to do; every guide exists in English and French. The specification is the normative version of all of it.

License

Apache-2.0. The rule identifiers, categories, titles and help links are read from a Microsoft analyzer, which is itself MIT-licensed.