migrate-nullable-references

Add <Nullable>enable</Nullable> to the .csproj PropertyGroup, then build and resolve the resulting CS86xx warnings. For large codebases, use a warnings-first or file-by-file strategy with #nullable enable per file to keep the warning volume manageable.

Decide whether null is valid by design: add ? to the declaration if so, or use the null-forgiving operator ! only when you can prove the value is never null. Avoid using ?. as a quick fix since it silently changes runtime behavior.

For reference types, annotations are metadata-only and do not change generated IL. However, EF Core infers column nullability from annotations and ASP.NET Core treats non-nullable properties as required, so those frameworks can change behavior.

Nullable reference types require C# 8.0 or later, which means .NET Core 3.0, .NET Standard 2.1, or newer. Projects on .NET Framework 4.x need an explicit <LangVersion>8.0</LangVersion> or higher, and C# 7.3 or earlier cannot use the feature.

Use ! only when you can prove the value is never null but the compiler cannot see why, and add a comment explaining the reasoning. If null is a valid state by design, annotate the type with ? instead of suppressing the warning.

EF Core reads nullable annotations via reflection and treats string properties as required NOT NULL columns while string? becomes nullable. Always review generated migrations after enabling NRTs on entity classes to avoid unintended AlterColumn operations on columns containing nulls.