.NET Null Safety: Why Your Legacy C# Code Suddenly Spams Warnings After Enabling Nullable Reference Types

The Warning Avalanche Problem

When you enable nullable reference types in an existing .NET project, you'll likely see hundreds of new warnings. This isn't a bug—it's the feature working correctly. The compiler is now tracking null states and warning when null could reach a non-nullable parameter.

Understanding the Annotation Syntax

Nullable reference types use two key annotations:

• ? - marks a reference type as nullable (can hold null)
• ! - null-forgiving operator, tells compiler to suppress warnings

Example:

public class Customer
{
    public string Name { get; set; }        // Non-nullable (warning if null assigned)
    public string? Email { get; set; }     // Explicitly nullable
    public void Process() => Console.WriteLine(Name.Length); // Warning if Name could be null
}

Flow Analysis in Action

The compiler tracks null states through code flow:

public void Example()
{
    string? input = null;
    if (input != null)
    {
        // Inside this block, compiler knows input is non-null
        Console.WriteLine(input.Length); // No warning here
    }
    // Outside block, input could still be null
}

Practical Migration Example

Here's how to handle a typical legacy class:

// Before migration - no null awareness
public class OrderProcessor
{
    private readonly ILogger _logger;
    
    public OrderProcessor(ILogger logger)
    {
        _logger = logger;
    }
    
    public Order FindOrder(int id)
    {
        return _db.Orders.FirstOrDefault(o => o.Id == id);
    }
}

// After migration - with null safety
#nullable enable

public class OrderProcessor
{
    private readonly ILogger _logger;
    
    public OrderProcessor(ILogger logger)
    {
        _logger = logger ?? throw new ArgumentNullException(nameof(logger));
    }
    
    public Order? FindOrder(int id)
    {
        return _db.Orders.FirstOrDefault(o => o.Id == id);
    }
}

The key changes:

1. Order? return type indicates method may return null
2. Constructor validates logger isn't null
3. Any code calling FindOrder must now handle potential null

Trade-offs and Limitations

While powerful, nullable reference types have important limitations:

• Runtime behavior unchanged - warnings don't prevent null exceptions at runtime
• False positives with generics - List<T> may generate spurious warnings
• Interop challenges - legacy APIs need [NullableContext] attributes
• Suppress then fix pattern - using ! without addressing root cause

Actionable Next Steps

Don't enable nullable reference types globally on day one. Instead:

1. Add <Nullable>enable</Nullable> to your .csproj for new code only
2. Use #nullable enable at file or method level for gradual adoption
3. Run dotnet fix to auto-apply suggestions
4. Address warnings systematically, starting with public API boundaries

Verify your changes compile cleanly and that all new warnings have intentional fixes or proper suppressions.