migrate-nullable-references

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

1|Updated Jun 1, 2026
One-click install
npx skills add https://github.com/D1ssolve/craft-agents --skill migrate-nullable-references-d1ssolve
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: migrate-nullable-references
Source: https://github.com/D1ssolve/craft-agents/tree/main/skills/migrate-nullable-references
Command: npx skills add https://github.com/D1ssolve/craft-agents --skill migrate-nullable-references-d1ssolve

SYSTEM DOCUMENTATION & REQUIREMENTS

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

What problem does it solve? Adopting nullable reference types (NRTs) in an existing C# codebase produces hundreds of CS86xx warnings and risks incorrect API contracts or accidental runtime behavior changes. This Skill provides a structured, step-by-step migration workflow that enables <Nullable>enable</Nullable>, resolves warnings in dependency order, and keeps the generated IL unchanged. ## Core Features & Use Cases - Readiness Assessment: Runs the Get-NullableReadiness.ps1 scanner to report <Nullable>, <LangVersion>, target frameworks, and existing suppression counts before starting. - Three Rollout Strategies: Supports project-wide enable, warnings-first, and file-by-file migration depending on codebase size and team activity. - Systematic Warning Resolution: Provides decision flowcharts and fix tables for CS8602, CS8600, CS8603, CS8604, CS8618, CS8625, and CS8601, plus guidance on nullable attributes like [NotNullWhen] and [MemberNotNull]. - Framework-Specific Guidance: Reference docs cover EF Core schema implications, ASP.NET Core model validation changes, and library breaking-change tracking. - Use Case: A team maintaining a large .NET library wants to enable NRTs without breaking consumers. The Skill migrates projects in dependency order, annotates public APIs conservatively, documents breaking changes in nullable-breaking-changes.md, and adds <WarningsAsErrors>nullable</WarningsAsErrors> to prevent regressions. ## Quick Start Enable nullable reference types in my C# solution at ./src/MyApp.sln and systematically fix all resulting nullable warnings without changing runtime behavior.

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 `<PropertyGroup>` in your .csproj file, then do a clean build to surface all warnings. For large codebases, use `<Nullable>warnings</Nullable>` first or add `#nullable enable` file-by-file to migrate incrementally.

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 you can prove the value is never null, use `!` with a justifying comment. Avoid `?.` as a quick fix since it silently changes runtime behavior.

Does enabling nullable reference types change runtime behavior?

No, NRT annotations are compile-time metadata only and do not change generated IL. However, adding `?.` operators or null checks during migration does change behavior, so the migration should use only annotations, attributes, and `!` operators.

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

Nullable reference types require C# 8.0 or later, which means .NET Core 3.0, .NET Standard 2.1, or .NET 5+. .NET Framework 4.x projects can use them only by explicitly setting `<LangVersion>8.0</LangVersion>` or higher.

How does enabling NRTs affect EF Core entity models?

EF Core reads nullable annotations to infer schema, treating `string` as required (NOT NULL) and `string?` as optional columns. Always review generated migrations after enabling NRTs, and use `#nullable disable` rather than `#nullable disable warnings` on unmigrated entity files.

When should I use the null-forgiving operator vs a null check?

Use `!` only when you can prove a value is never null but the compiler cannot see why, and add a comment explaining the reasoning. Prefer explicit null checks, nullable type annotations, or attributes like `[NotNullWhen]` over scattering `!` to silence warnings.