C# "CS8600: converting null literal to non-nullable type" in CI

By Kaveh Alemi·Latchkey

CS8600 means a null or possibly-null value is being assigned to a variable typed as non-nullable. With nullable enabled and warnings as errors, CI fails on it. It is the compiler telling you the static null-flow does not prove non-nullness.

What this error means

The build fails with CS8600 at the assignment. It is deterministic and frequently CI-only because of warnings-as-errors.

Parsing.cs(15,13): error CS8600: Converting null literal or possible null value to
non-nullable type.

Diagnose it: SDK version and restore first

Most .NET CI failures are an SDK mismatch or a restore that did not happen. global.json pins the SDK, and if the runner does not have that exact version the failure message is about the project rather than the SDK.

dotnet --info
cat global.json 2>/dev/null

# restore explicitly so a restore failure is not reported as a build failure
dotnet restore --verbosity normal
dotnet build --no-restore -warnaserror

Common causes

A possibly-null result assigned to a non-nullable variable

A method returning a nullable reference (e.g. a dictionary TryGet pattern or FirstOrDefault) is stored in a non-nullable local without a null check.

CI treats nullable warnings as errors

The build pipeline enables warnings-as-errors, so this otherwise-warning fails CI.

How to fix it

Make the nullability explicit

1. Declare the local as nullable (string?) and handle the null branch.
2. Or guard with a null check / null-forgiving ! only when you can prove non-null.
3. Rebuild.

string? name = items.FirstOrDefault();
if (name is null) return;

How to prevent it

• Keep nullable reference types enabled throughout the codebase.
• Prefer pattern-based null checks over null-forgiving operators.

Frequently asked questions

Related guides

References

• .NET documentation
• GitHub Actions documentation