DiagnosticCatalog.MSTest 1.0.0

DiagnosticCatalog.MSTest

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

The MSTest.Analyzers rules as strongly referenced constants, so that SuppressMessageAttribute takes compile-checked references instead of magic strings.

🪞 Mirrors MSTest.Analyzers 4.3.3

62 rules, 3 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

Every MSTest project runs these analyzers, and almost nobody installed them: MSTest.TestFramework depends on MSTest.Analyzers, so the MSTest meta-package and MSTest.TestAdapter both drag them in. They arrive with the test framework.

That is what makes their rules the ones people suppress in source. A rule you switched on gets tuned in .editorconfig; a rule that arrived with the framework gets an exception at the one place it is wrong, with a Justification beside the test that earns it.

MSTest sharpens this further than the other test frameworks do, because it ships rules that contradict each other on purpose: MSTEST0019 prefers TestInitialize methods over constructors and MSTEST0020 prefers constructors over TestInitialize methods; MSTEST0021 prefers Dispose over TestCleanup and MSTEST0022 prefers the reverse. You pick a side, and the other rule of the pair is one you will be answering for the life of the project.

[SuppressMessage("Usage", "MSTEST0037:Use proper 'Assert' methods", Justification = "…")]

Three strings, and nothing checks any of them. 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.MSTest;

[SuppressMessage(
    MSTestRule.MSTEST0037.Category,
    MSTestRule.MSTEST0037.Id,
    Justification = "The overload this rule suggests does not exist for this comparer.")]

The day a rule moves to another category, the second version follows it and the first is left naming a category the rule no longer carries — silently, and for as long as the line survives.

Installation

<PackageReference Include="DiagnosticCatalog.MSTest" 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. A literal suppression a catalogue reference would replace is an error by default, and a code fix rewrites it for you.

What is in the package

62 rules across 3 categories, and every one of the 62 carries both the title its descriptor declares and a help link into Microsoft Learn — a completeness only the xUnit and NUnit catalogues here match.

[DiagnosticRule]
public static class MSTEST0037
{
    public const string Id = nameof(MSTEST0037);
    public const string Category = MSTestCategory.Usage;
    public const string HelpLinkUri = "https://learn.microsoft.com/dotnet/core/testing/mstest-analyzers/mstest0037";
}

Where MSTest files an assertion rule, and why you cannot guess it

If you run more than one test framework across a solution — a migration, a mixed monorepo — this is the trap worth naming. Take one concept, "this assertion is wrong", and ask each framework what category it belongs to:

xUnit and NUnit differ by one letter. MSTest does not have an assertion category at all: it splits them by what kind of mistake they catch. MSTEST0037 Use proper 'Assert' methods is Usage; MSTEST0032 Assertion condition is always true is Design; MSTEST0025 Use 'Assert.Fail' instead of an always-failing assert is Design too.

So even knowing the framework does not tell you the answer — you have to know the rule. And nothing in the platform reads that argument, so a wrong one costs no error and no warning, ever. Reaching it through MSTestRule.MSTEST0037.Category removes the question.

Categories declared once

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

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.

dotnet run --project src/DiagnosticCatalog.Cli -- generate \
    --package MSTest.Analyzers --package-version latest \
    --namespace DiagnosticCatalog.MSTest --container MSTestRule \
    --output src/DiagnosticCatalog.MSTest/MSTestRules.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 mstest release train and versions independently of the foundation, so it can follow MSTest.Analyzers' releases without dragging anything else along.

Publishing is not part of the nightly. A maintainer pushes an mstest-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.

Limits

[SuppressMessage] cannot suppress compiler warnings — CS0219 and friends need #pragma warning disable, which takes bare identifiers and so can never reference a constant. This package covers the MSTESTxxxx analyzer rules only.

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.
• Adopting a catalogue on an existing codebase — the severity ramp, Fix all occurrences, scoping by folder, and what order to convert in.
• 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 third-party analyzer, which is itself MIT-licensed.