dotnet Analyzer Warnings as Errors (CAxxxx) Break CI

Roslyn analyzers (CAxxxx code-analysis rules, or third-party analyzers) emit warnings that a warnings-as-errors policy turns into build failures. Enabling EnforceCodeStyleInBuild or AnalysisMode can surface many at once.

What this error means

Build fails on a CAxxxx (or analyzer-specific) code reported as an error. It often appears right after adding an analyzer package, raising AnalysisLevel, or turning on EnforceCodeStyleInBuild in CI.

error CA1822: Member 'Compute' does not access instance data and can be marked as static
[analyzer warnings treated as errors]

Common causes

Analyzer rules promoted to errors

A warnings-as-errors policy (or per-rule error severity) makes analyzer findings fatal. The rule is firing legitimately; the severity is what breaks the build.

A new analyzer package or higher AnalysisLevel

Adding an analyzer package, or raising AnalysisLevel/AnalysisMode, activates rules that were previously silent, producing new CAxxxx errors.

How to fix it

Fix the flagged rule

Apply the analyzer’s suggestion (e.g. mark a method static for CA1822) - the durable fix.

// CA1822: mark members that don't use instance state as static
private static int Compute(int a, int b) => a + b;

Tune the rule severity in .editorconfig

When a rule is not wanted as an error, set its severity narrowly rather than disabling all analyzers.

# .editorconfig
[*.cs]
dotnet_diagnostic.CA1822.severity = suggestion

How to prevent it

• Configure analyzer severities in a committed .editorconfig shared by all projects.
• Introduce a new analyzer or higher AnalysisLevel behind a cleanup PR, not all at once.
• Run analyzers locally (EnforceCodeStyleInBuild) so findings surface before CI.

Related guides