CS8618: Non-nullable property 'Name' must contain a non-null value when exiting constructor. — the property is declared as never null, but nothing gives it a value. Mark it required, give it a default such as = string.Empty, or declare it string? if null is a real value.

A short rule: required for DTOs and entities you create in code, a default for options classes bound from configuration, and string? for data that may truly be missing.

The error

By default it is a warning and the build succeeds:

...\CsLab\Patient.cs(6,19): warning CS8618: Non-nullable property 'Name' must contain a non-null value when exiting constructor. Consider adding the 'required' modifier or declaring the property as nullable. [...\CsLab\CsLab.csproj]

With <TreatWarningsAsErrors>true</TreatWarningsAsErrors> in the project file it stops the build:

...\CsLab\Patient.cs(6,19): error CS8618: Non-nullable property 'Name' must contain a non-null value when exiting constructor. Consider adding the 'required' modifier or declaring the property as nullable. [...\CsLab\CsLab.csproj]

Build FAILED.

Only the folder paths are shortened; nothing else is changed.

Why it happens

The .NET project templates switch on nullable reference types with <Nullable>enable</Nullable>. From then on string means "never null" and string? means "may be null", and the compiler checks that every constructor leaves each non-nullable property with a value. This class has no constructor that sets Name, so it starts life as null and breaks its own promise:

public class Patient
{
    public int Id { get; set; }
    public string Name { get; set; }
}

The fix

public class Patient
{
    public int Id { get; set; }
    public required string Name { get; set; }
}

required moves the promise to the caller. Every new Patient { ... } that leaves out Name now fails to compile with CS9035: Required member 'Patient.Name' must be set in the object initializer or attribute constructor. System.Text.Json honours it too: JSON without Name threw JsonException instead of producing a patient with no name. EF Core loaded entities with a required property without trouble and created the column as NOT NULL. That makes it the right choice for DTOs, records and entities.

    public string Name { get; set; } = string.Empty;

A default suits options classes. The configuration binder creates the object itself and ignores required: in the lab, a missing key left a required property null with no complaint. A default keeps the promise; add validation if an empty value is not acceptable.

    public string? Name { get; set; }

Nullable is for data that can really be absent, such as a phone number. The compiler then makes you check before use: p.Name.Length became CS8602: Dereference of a possibly null reference. EF Core maps it to a nullable column.

How it was reproduced

A console app from dotnet new console -o CsLab on .NET SDK 10.0.401 (target net10.0, nullable enabled by the template) with the Patient class above. dotnet build printed the warning and succeeded; adding TreatWarningsAsErrors turned it into an error and the build failed. Each of the three fixes then built with zero warnings, warnings-as-errors still on. The side checks used System.Text.Json from the runtime, Microsoft.Extensions.Configuration.Binder 10.0.12 and Microsoft.EntityFrameworkCore.Sqlite 10.0.12.

Frequently asked

How do I fix CS8618 in C#?
Make sure the property always has a value. Add the required modifier so every caller must set it, give it a default such as = string.Empty, or declare it nullable with string? when null is a valid value.
Should EF Core entity properties use required or string?
Use required string for columns that must have a value; EF Core creates them as NOT NULL and loads such entities without trouble. Use string? for optional columns, which EF Core creates as nullable.
Can I use required on an ASP.NET Core options class?
It compiles, but the configuration binder does not enforce it: a missing key leaves the property null. Give options properties a default and validate them if an empty value is not acceptable.

More decoded errors in the Fixes category.