Analyzers

The strongest analyzer story to promote first is the one developers already have: the SDK, compiler, and editor already ship first-party guidance for code quality, style, platform safety, and nullability.

• Turn on EnableNETAnalyzers when a project does not already get the built-in CA rules by default.
• Use AnalysisLevel, AnalysisMode, CodeAnalysisTreatWarningsAsErrors, and EnforceCodeStyleInBuild to decide how aggressively builds and CI enforce the official baseline.
• Use Microsoft.CodeAnalysis.NetAnalyzers only when you need the official package-based path for older targets or a NuGet-driven update cadence.

Turn on: Use EnableNETAnalyzers, AnalysisLevel, AnalysisMode, CodeAnalysisTreatWarningsAsErrors, and EnforceCodeStyleInBuild in the project file, then set per-rule severities with dotnet_diagnostic.<ID>.severity in .editorconfig.

Example rules: CA1822, IDE0028, CS8602

Encourages: turn built-in analyzers on before adding custom ones, roll out severities deliberately across editor and CI

Official IDE rules make modern C# adoption incremental instead of disruptive: start with suggestions in the editor, then promote the patterns that help this codebase most.

// Before
public static class BeforeCollectionExpressionSample
{
    public static int[] CreateValues()
    {
        return new int[] { 1, 2, 3 };
    }
}

// After (C# 12+)
public static class AfterCollectionExpressionSample
{
    public static int[] CreateValues()
    {
        return [1, 2, 3];
    }
}

That same official style rule family also covers pattern matching (IDE0019), using declarations (IDE0063), and primary constructors (IDE0290) through .editorconfig options and per-rule severities.

Turn on: Configure style options in .editorconfig, turn on EnforceCodeStyleInBuild when you want build-time enforcement, and promote individual IDE rules with dotnet_diagnostic.<ID>.severity.

Example rules: IDE0028, IDE0019, IDE0063, IDE0290

Encourages: collection expressions, pattern matching, using declarations, primary constructors

Consistency-focused IDE rules keep cleanup passes predictable, especially when the team is modernizing syntax in small batches instead of one disruptive rewrite.

// Before
public static class BeforeCustomerGuards
{
    public static bool IsMissing(object? customer)
    {
        return object.ReferenceEquals(customer, null);
    }
}

// After
public static class AfterCustomerGuards
{
    public static bool IsMissing(object? customer)
    {
        return customer is null;
    }
}

The same configuration story also covers file-scoped namespaces (IDE0161, C# 10+) so formatting and structure stay aligned across the repo.

Turn on: Keep the preferred style options in .editorconfig, use EnforceCodeStyleInBuild for build enforcement, and raise or lower individual IDE severities as the repo settles on conventions.

Example rules: IDE0041, IDE0161

Encourages: is null checks, file-scoped namespaces, repeatable cleanup passes

The CA analyzer families move reliability, performance, security, and API-usage guidance into the build so reviewers do not have to rediscover the same issues by hand.

// Before
public sealed class BeforeNameFormatter
{
    public string Normalize(string value) => value.Trim();
}

// After
public sealed class AfterNameFormatter
{
    public static string Normalize(string value) => value.Trim();
}

That is only one example: the same official set also flags missed disposal paths (CA2000) and weak cryptography choices (CA5350).

Turn on: Keep EnableNETAnalyzers on, choose AnalysisLevel and AnalysisMode for the rollout you want, and use CodeAnalysisTreatWarningsAsErrors plus per-rule severities to decide what CI blocks.

Example rules: CA1822, CA2000, CA5350

Encourages: safer framework usage, deterministic disposal, stronger cryptography choices

Platform compatibility analysis deserves its own callout because it teaches safer use of OS-specific APIs instead of leaving those rules to tribal knowledge.

using Microsoft.Win32;

// Before
public static class BeforePlatformSamples
{
    public static object? ReadInstallPath()
    {
        return Registry.GetValue(@"HKEY_LOCAL_MACHINE\SOFTWARE\Contoso", "InstallPath", null);
    }
}

// After
public static class AfterPlatformSamples
{
    public static object? ReadInstallPath()
    {
        if (!System.OperatingSystem.IsWindows())
        {
            return null;
        }

        return Registry.GetValue(@"HKEY_LOCAL_MACHINE\SOFTWARE\Contoso", "InstallPath", null);
    }
}

CA1416 is the official rule to watch here, backed by target-framework context, platform attributes, and runtime guards.

Turn on: The platform analyzer rides with the official analyzer stack; for older targets you can set AnalysisLevel and dotnet_code_quality.enable_platform_analyzer_on_pre_net5_target, then tune dotnet_diagnostic.CA1416.severity.

Example rules: CA1416

Encourages: OperatingSystem guards, SupportedOSPlatform attributes, safer cross-platform APIs

Nullable analysis is compiler-backed static analysis rather than a separate analyzer package, but it belongs in the same official-first rollout because it hardens API contracts early.

// Before
public static class BeforeTextSamples
{
    public static int LengthOrZero(string? value)
    {
        return value.Length;
    }
}

// After
public static class AfterTextSamples
{
    public static int LengthOrZero(string? value)
    {
        return value is null ? 0 : value.Length;
    }
}

That same nullable story also includes constructor and property initialization guidance such as CS8618 once <Nullable>enable</Nullable> is part of the project baseline.

Turn on: Enable nullable analysis with Nullable in the project file, then use nullable annotations, attributes, and per-warning severity choices to tighten the rollout over time.

Example rules: CS8602, CS8618

Encourages: explicit nullability, guarded dereferences, initialized non-null state