I use .NET 5 (Core) for my app. I would like to know what is the best practice to allow server doing migrations script on Production ? Should I create migrations script --idempotent and run dotnet ef database update on the server ? Or should I give the client pieces of migration scripts and do the update on there ? Should I put automating the migrationscript on the compiled app ?
Asked
Active
Viewed 379 times
1
-
Does this answer your question? [How to apply EF Core migrations if you should not use MigrateAsync() for production environments?](https://stackoverflow.com/questions/67761614/how-to-apply-ef-core-migrations-if-you-should-not-use-migrateasync-for-product) – keipala Nov 03 '22 at 07:36
1 Answers
3
Here's the Microsoft documentation about migrations in production.
You can call the Database.Migrate();
inside the constructor of your Db Context class or in the dependency inversion process create a scope of the Db Context class and call:
var db = scope.ServiceProvider.GetRequiredService<ApplicationDbContext>();
db.Database.Migrate();
But, be aware of the warning:
- Carefully consider before using this approach in production. Experience has shown that the simplicity of this deployment strategy is outweighed by the issues it creates.
- Consider generating SQL scripts from migrations instead. Don't call EnsureCreated() before Migrate(). EnsureCreated() bypasses Migrations to create the schema, which causes Migrate() to fail.

wbail
- 536
- 1
- 7
- 18