Skip to content
Latchkey

Roslyn analyzer diagnostic promoted to error in CI

Analyzer diagnostics (the CA* code-quality rules, IDE* style rules, or third-party analyzers) normally surface as warnings. When the project enables TreatWarningsAsErrors or AnalysisMode=All, CI turns them into hard errors that fail the build even though the code compiles.

What this error means

The build fails with an error whose code is an analyzer id (e.g. CA2007, IDE0058) rather than a CSxxxx compiler error. It is deterministic and often CI-only due to stricter settings.

dotnet
Service.cs(33,9): error CA2007: Consider calling ConfigureAwait on the awaited task
[/work/src/Api/Api.csproj]

Common causes

TreatWarningsAsErrors promotes analyzer warnings

The project (or Directory.Build.props) enables warnings-as-errors, so analyzer diagnostics become build-breaking errors.

A stricter AnalysisMode in CI

AnalysisMode=All or a higher analysis level enables rules that did not fire under the developer default.

How to fix it

Fix the diagnostic or scope the severity

  1. Address the analyzer finding in code (the correct long-term fix).
  2. If a rule is intentionally not applicable, set its severity in .editorconfig (e.g. dotnet_diagnostic.CA2007.severity = none) rather than disabling all warnings-as-errors.
  3. Rebuild.
.editorconfig
# .editorconfig
[*.cs]
dotnet_diagnostic.CA2007.severity = none

How to prevent it

  • Run the same analysis level locally as CI so findings appear early.
  • Tune analyzer severity per rule in .editorconfig, not by blanket-disabling.

Frequently asked questions

What causes ""error CAxxxx / IDExxxx: ...""?
The project (or Directory.Build.props) enables warnings-as-errors, so analyzer diagnostics become build-breaking errors.
How do I fix "error CAxxxx / IDExxxx: ..."?
Fix the diagnostic or scope the severity

Related guides

References

Latchkey auto-heals failures like this one - detected, fixed, and retried without you. Start free → 30-day trial · No credit card