The Error

Build warning in.NET 8:

CS8618: Non-nullable property 'Name' must contain a non-null value when exiting constructor. Consider declaring the property as nullable.

Quick Fix - 10 Seconds

.NET 8 enables nullable reference types by default. Fix with = null! or required.

Option 1 - For EF Core entities:

public class User
{
    public int Id { get; set; }
    public string Name { get; set; } = null!; // Tell compiler EF sets this
    public string? Bio { get; set; } // This one can be null
}

Option 2 - For DTOs: Use required keyword:

public class CreateUserDto
{
    public required string Name { get; set; }
    public string? Bio { get; set; }
}

Why This Happens

.NET 8 projects have <Nullable>enable</Nullable> in csproj. The compiler forces you to handle nulls. string Name means "this is NEVER null". But constructors don't set it, so compiler warns.

Step-by-Step: How to Fix

EF Entities: Add = null! to non-nullable strings. EF sets them from DB
DTOs: Use required keyword. Forces caller to provide value
Optional fields: Make them string? if DB allows NULL
Disable project-wide: Set <Nullable>disable</Nullable> - not recommended

Common Scenarios

EF Core models: All string properties warn because DB columns are NOT NULL
DTOs/records: Constructor params vs property setters mismatch
JSON deserialization: System.Text.Json needs required or setters

Real-World Scenario: EF Core + JSON API

This warning explodes when mixing EF entities with API DTOs:

// EF Entity - DB fills Name, so we use null!
public class Customer {
    public int Id { get; set; }
    public string Name { get; set; } = null!; // DB is NOT NULL
}
// API DTO - Caller must provide Name
public class CreateCustomerDto {
public required string Name { get; set; } // Compiler enforces
}

Why both? EF uses reflection to set Name after construction. null! silences CS8618. For DTOs, required forces the API caller to send Name or you get a 400 error.

Debugging Checklist

Check if it's EF entity: If yes, use = null! - EF promises to set it
Check if it's DTO: If yes, use required - API must send it
Check DB schema: If column allows NULL, use string? instead
Check JSON payload: Missing field + non-nullable = CS8618. Add required or make string?

FAQ - Featured Snippet Targets

Q: What does = null! mean in C#?

The null-forgiving operator. Tells compiler "trust me, this won't be null at runtime". Used for EF entities where DB/reflection sets the value after constructor.

Q: Should I use required or null! for.NET 8 entities?

Use = null! for EF entities. Use required for DTOs/records. Never use = null! on DTOs - hides bugs.

Best Practice for.NET 8

1. Keep nullable enabled: Catches null bugs at compile time

2. Use required: Better than = null! for DTOs

3. Use string? Email: If DB column allows NULL

// Perfect.NET 8 entity
public class Product
{
    public int Id { get; set; }
    public required string Name { get; set; } // Must be set
    public string Description { get; set; } = null!; // EF sets this
    public string? SKU { get; set; } // Can be null
}

Fix: CS8618 Non-nullable property must contain non-null value