dotnet Nullable Warnings as Errors (CS8600, CS8602) in CI

Turning on nullable reference types (<Nullable>enable</Nullable>) plus a warnings-as-errors policy makes every nullability warning a build error. CS8600/CS8602/CS8618 then fail CI for code that compiled before.

What this error means

Build fails on CS8602 ("dereference of a possibly null reference"), CS8618 ("non-nullable field must contain a non-null value"), or similar, reported as errors. It typically appears right after enabling nullable annotations or a context bump.

dotnet build output

error CS8602: Dereference of a possibly null reference.
error CS8618: Non-nullable property 'Name' must contain a non-null value when exiting
constructor. Consider adding the 'required' modifier or declaring as nullable.

Common causes

Nullable enabled with warnings-as-errors

With nullable annotations on and warnings-as-errors set, the compiler’s null-safety warnings become fatal. The findings are real null hazards; the policy makes them block the build.

Newly annotated code or dependency surface

Adding <Nullable>enable</Nullable> to more projects, or upgrading a dependency that added nullable annotations, surfaces warnings that were previously absent.

How to fix it

Fix the nullability at the source

Initialize non-nullable members, guard dereferences, or use required/nullable annotations to express intent.

public required string Name { get; init; }   // CS8618

if (user is not null)
    Console.WriteLine(user.Email);            // CS8602

Stage nullable adoption per project

Roll nullable out gradually rather than enabling it everywhere with warnings-as-errors at once.

.csproj

<!-- enable per project, fix, then expand -->
<Nullable>enable</Nullable>
<!-- or 'warnings' to annotate without breaking the build yet -->

How to prevent it

Adopt nullable reference types project-by-project, fixing warnings as you go.
Use required members and explicit null checks to satisfy the analyzer.
Build locally with the same nullable + warnings-as-errors settings as CI.