In my opinion, it is your first point (Database.Migrate() due startup) that meets mostly our use case. So for me, it`s currently the preferred way to do that.
We have some additional constellations in the starting up process:
-
Docker container locally only (for dev environment and testing for sure)
-
Own startup project which executes the Database.Migrate() part (cause we have more than one project with its own database)
-
Additional project with the actually API website 🙂
-
Production environment with Azure SQL server (Published and deployed through Azure DevOps pipeline
-
Migrations are created in its own project via dotnet ef …
dotnet ef migrations add “your migration name” –startup-project “path to your actually API” –context “database context name”
Important:
you have to change the working directory to the migration project first in order to use another startup project but generate the migration files in the “migration project”
In our case, it works fine with different APIs with their own databases behind the scene.
Regards