Skip to content
Latchkey

dotnet "warning treated as error" - TreatWarningsAsErrors in CI

Your build has TreatWarningsAsErrors enabled, so a compiler warning that would normally be benign fails the build. CI surfaces it even though local dev (without the flag) compiled fine.

What this error means

Build fails on a warning CSxxxx ... [treated as error] line - nullability, unused variable, obsolete API. It often passes locally because the warnings-as-errors setting only bites in the CI configuration.

dotnet build output
Program.cs(20,13): error CS8602: Dereference of a possibly null reference.
       [/src/MyApp/MyApp.csproj]
##[error]Process completed with exit code 1.

Common causes

TreatWarningsAsErrors is on in the build config

The project or a Release configuration sets <TreatWarningsAsErrors>true</TreatWarningsAsErrors>, so any warning fails the build.

New analyzer or nullable warning introduced

An SDK bump or new analyzer raises warnings the code never triggered before, which then become errors under the flag.

How to fix it

Fix the underlying warning

The right fix is to resolve the warning - add the null check, remove the unused symbol, replace the obsolete API.

C#
// CS8602: guard the possibly-null reference
if (user is not null)
    Console.WriteLine(user.Name);

Scope-suppress a specific warning if justified

When a warning is a known false positive, suppress that code narrowly rather than disabling all warnings-as-errors.

.csproj
<PropertyGroup>
  <WarningsNotAsErrors>CS8602;CS0618</WarningsNotAsErrors>
</PropertyGroup>

How to prevent it

  • Build with the same TreatWarningsAsErrors setting locally as CI uses.
  • Address warnings as they appear instead of letting them accumulate.
  • Pin analyzer/SDK versions so new warnings don’t appear unexpectedly.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →