This sample show how to use EFCore Migrations when your application is split up into seperate assemblies or architectural layers.
This sample application is split into four assemblies.
Assembly | Description |
---|---|
MyApp.Data | Contains the DbContext |
MyApp.Migrations | Contains migration classes and the model snapshot |
MyApp.Models | Contains POCO entity type classes |
MyApp.Web | The web app. Configures the DbContext |
To run the commands, MyApp.Migrations
should be used as the target project (Default project or -Project
in PMC,
and --project
in CLI), and MyApp.Web
as the startup project (-StartupProject
in PMC, and --startup-project
in
CLI).
cd ./MyApp.Migrations/
dotnet ef migrations add Migration2 --startup-project ../MyApp.Web/
There are a few parts of the sample that deserve some attention.
Look at the project and package references. Anywhere you see PrivateAssets="All"
, it means that that reference should
be available during development, but shouldn't get published to the server.
In Startup.ConfigureServices()
, we tell the DbContext
where to find the migrations classes:
optionsBuilder.UseSqlServer(
connectionString,
x => x.MigrationsAssembly("MyApp.Migrations"));