migrate-nullable-references

Enable C# nullable reference types and systematically resolve CS86xx warnings across projects.

Updated Jul 20, 2026
One-click install
npx skills add https://github.com/Netcodr81/kinetic-reports --skill migrate-nullable-references-netcodr81
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: migrate-nullable-references
Source: https://github.com/Netcodr81/kinetic-reports/tree/main/.github/skills/migrate-nullable-references
Command: npx skills add https://github.com/Netcodr81/kinetic-reports --skill migrate-nullable-references-netcodr81

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Migrating an existing C# codebase to nullable reference types (NRTs) produces hundreds of CS86xx warnings and risks incorrect annotations that mislead consumers or silently change runtime behavior. This Skill provides a structured, step-by-step workflow to enable <Nullable>enable</Nullable>, resolve every warning category correctly, and keep the generated IL unchanged. ## Core Features & Use Cases - Readiness scanning: The Get-NullableReadiness.ps1 script reports <Nullable>, <LangVersion>, and <TargetFramework> settings plus counts of #nullable directives, ! operators, and #pragma suppressions, with JSON output for automation. - Phased migration workflow: Choose project-wide, warnings-first, or file-by-file rollout strategies, then fix dereference warnings (CS8602/CS8600/CS8603/CS8604), annotate declarations (CS8618/CS8625/CS8601), apply nullable attributes like [NotNullWhen] and [MemberNotNull], and clean up suppressions. - Framework-specific guidance: Reference docs cover EF Core schema inference, ASP.NET Core model validation, and library breaking-change tracking so annotations do not cause unintended runtime or consumer impact. - Use Case: A team maintaining a large .NET library wants to adopt NRTs without breaking consumers. The Skill migrates projects in dependency order, annotates the public API surface conservatively, documents breaking changes in nullable-breaking-changes.md, and adds <WarningsAsErrors>nullable</WarningsAsErrors> to prevent regressions. ## Quick Start Ask the AI to enable nullable reference types in your C# project and resolve all resulting nullable warnings using this migration workflow.

Frequently Asked Questions about migrate-nullable-references

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enable nullable reference types in an existing C# project?▼

Add <Nullable>enable</Nullable> to the .csproj PropertyGroup, then build and resolve the resulting CS86xx warnings in phases: dereference warnings first, then annotation warnings, then nullable attributes. For large codebases, use a warnings-first or file-by-file strategy with #nullable enable per file.

How to fix CS8602 dereference of possibly null reference warnings?▼

Decide whether null is valid by design: if yes, make the upstream type nullable with ?; if the value is provably non-null, use ! with a justifying comment. Avoid adding ?. or null checks as quick fixes since they change runtime behavior during an annotation-only migration.

Does enabling nullable reference types change runtime behavior?▼

For reference types, NRT annotations are metadata-only and do not change generated IL. However, adding ? to value types changes them to Nullable<T>, and frameworks like EF Core and ASP.NET Core read annotations at runtime to infer schema nullability and model validation rules.

Can I use nullable reference types with .NET Framework or C# 7?▼

No. Nullable reference types require C# 8.0 or later, which means .NET Core 3.0, .NET Standard 2.1, or .NET 5+. Projects on .NET Framework 4.x must set <LangVersion>8.0</LangVersion> or higher explicitly before enabling NRTs.

When should I use [NotNullWhen] and [MemberNotNull] attributes?▼

Use [NotNullWhen(true)] on Try-pattern or validation methods so callers know an out parameter is non-null on success. Use [MemberNotNull] on helper methods that initialize fields after construction, so the compiler treats those fields as non-null after the call.

Why should I avoid return null! during NRT migration?▼

Writing return null! hides a null behind a non-nullable return type, so callers trust the signature, skip null checks, and hit NullReferenceException at runtime. If a method can return null, its return type must be T? instead.