EF Core 11: migrations get friendlier for teams

EF Core 11 brings a set of small changes that remove daily friction from migrations work. You can keep a relationship in the model without a foreign key constraint in the database, the model snapshot now surfaces diverged migrations at merge time, a single command can scaffold and apply a migration, and dotnet ef gets a configuration file. Any .NET team working on a shared codebase will feel the difference.

Key points

• `ExcludeForeignKeyFromMigrations()` keeps the relationship in the model but drops the foreign key constraint from migrations; the OrderId index stays
• Without the constraint, orphaned rows and cascade deletes are no longer enforced by the database, so integrity moves into your code
• The model snapshot now stores the latest migration ID, so migrations added on two branches conflict at merge time
• `dotnet ef database update <Migration> --add` compiles the migration with Roslyn and applies it in a single command
• A `.config/dotnet-ef.json` file can hold project, startupProject and context defaults; command-line arguments still win
• `--context "*"` runs migrations list, script, database update and database drop for every DbContext in the project

EF Core 11 ships with .NET 11 and focuses a good part of its changes on how teams handle migrations. The new `ExcludeForeignKeyFromMigrations()` call keeps a relationship fully in the model, with navigation properties and change tracking intact, while leaving the foreign key constraint out of the database; the index on OrderId is still created. The model snapshot now records the latest migration ID, so two branches that each add a migration collide at merge instead of silently corrupting the snapshot.

`database update --add` scaffolds a migration, compiles it with Roslyn and applies it in one step, still writing the files to disk. A `.config/dotnet-ef.json` file removes the need to type `--project` and `--startup-project` on every command, and `--context "*"` runs commands against every DbContext in the project.

Real-world use

• Migrating an app onto EF Core against a legacy database whose existing data can't satisfy a new foreign key constraint
• An import or sync job where records arrive out of order, so order lines may be written before their orders
• A Clean Architecture solution where the DbContext lives in Infrastructure and the connection string in the Web project, so no one has to retype long commands
• A project with both a domain DbContext and an audit DbContext that needs its test databases reset and migrated in one command

Why it matters

Migrations are something every team touches constantly; these changes surface merge conflicts while the change is still fresh instead of weeks later and remove the long command lines every new team member had to learn.

Related stories

• EF Core vs redb: an object graph against 54 tables and IncludeDVDEV Community: #dotnet1 d ago
• Agent Framework builder skills for .NET and Python coding agentsAFMicrosoft Agent Framework Blog1 d ago
• The handler signature that kept growing: using [AsParameters] in minimal APIsDVDEV Community: #aspnetcore1 d ago