migrate-nullable-references

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

Updated Sep 22, 2026
One-click install
npx skills add https://github.com/bytecakelake/Nurse-Scheduler --skill migrate-nullable-references-bytecakelake
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: migrate-nullable-references
Source: https://github.com/bytecakelake/Nurse-Scheduler/tree/main/.agents/plugins/dotnet-upgrade/skills/migrate-nullable-references
Command: npx skills add https://github.com/bytecakelake/Nurse-Scheduler --skill migrate-nullable-references-bytecakelake

SYSTEM DOCUMENTATION & REQUIREMENTS

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

What problem does it solve? Adopting nullable reference types in an existing C# codebase produces hundreds of CS86xx warnings with no clear order of attack, and careless fixes (sprinkling ! or ?.) silently change runtime behavior or hide NullReferenceExceptions. This Skill provides a structured, zero-behavior-change migration workflow that enables <Nullable>enable</Nullable>, resolves warnings in dependency order, and produces accurately annotated public API surfaces. ## Core Features & Use Cases - Readiness scanning: Run the included Get-NullableReadiness.ps1 script to report <Nullable>, <LangVersion>, and <TargetFramework> settings plus counts of #nullable disable directives, ! operators, and CS86xx pragma suppressions. - Three rollout strategies: Choose project-wide enable, warnings-first, or file-by-file migration based on codebase size, migrating in dependency order from core models outward. - Framework-specific guidance: Reference docs cover EF Core schema inference, ASP.NET Core model validation, nullable attributes like [NotNullWhen] and [MemberNotNull], and library breaking-change tracking. - Use Case: A team maintaining a large .NET library wants to ship nullable annotations so consumers get accurate nullability information. The Skill scans readiness, enables NRTs project-by-project, fixes CS8602/CS8618 warnings with annotation-only changes, and documents breaking changes in nullable-breaking-changes.md. ## 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 do a clean build to surface all CS86xx warnings. For large codebases, use <Nullable>warnings</Nullable> first or add #nullable enable file-by-file in dependency order.

How to fix CS8602 and CS8618 nullable warnings without changing behavior?▼

For CS8602 dereference warnings, make the upstream type nullable (T?) if null is valid, or use ! only when the value is provably non-null. For CS8618 uninitialized members, initialize in the constructor, mark required, or use = null! for late-initialized fields.

Does enabling nullable reference types affect EF Core database schema?▼

Yes. EF Core reads nullable annotations via reflection, treating string as required (NOT NULL) and string? as optional columns. Always review generated migrations after enabling NRTs on entity classes to avoid unintended AlterColumn changes.

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+. .NET Framework 4.x projects must set <LangVersion>8.0</LangVersion> or higher explicitly before enabling NRTs.

Why should I avoid using the null-forgiving operator to silence warnings?▼

Each ! operator claims a value is never null; if wrong, it hides a NullReferenceException from the compiler. Prefer explicit null checks, nullable type annotations, or attributes like [NotNullWhen] that give the compiler real flow information.

When should I use [NotNullWhen] versus [MaybeNullWhen] attributes?▼

Use [NotNullWhen(true)] on non-generic Try-method out parameters declared nullable (MyType?). Use [MaybeNullWhen(false)] on generic out parameters kept non-nullable, since T? on unconstrained generics changes value-type signatures to Nullable<T>.