EF Code Management First Migrations Between Development and Production

Question

Very briefly:

I implemented EF Migrations in an existing project built as Code First, based on an article by Ladislav Mrnka

When implementing EF Migrations in a project that is already in production, how can you manage the migration scripts between the updates applied to Development and then the scripts generated for Production?

The reason I'm puzzled is because the MigrationId generated for each script added a TimeStamp to it. In my migration attempts, I noticed that the entries recorded in the __MigrationHistory tables on dev and prod are different, which raises the question if there had to be a lot of migration updates for the database, then if for some reason a downgrade was required, It would be very it's hard to link the exact MigrationId to script using update-database -script

---

A very direct process when you create a $InitialMigration that creates a __MigrationHistory table. Then, any changes in your model are followed by any update-database to get the Migrated database. And this process loops whenever you have a logically grouped batch of model changes.

__MigrationHistory look at the __MigrationHistory table, showing

 +------------------------------------+-------------------------+------------------------------------------------------------------+----------------+ | MigrationId | CreatedOn | Model | ProductVersion | +------------------------------------+-------------------------+------------------------------------------------------------------+----------------+ | 000000000000000_BootstrapMigration | 2012-03-01 17:40:39.567 | 0x1F8B08000000400ECBD07601C49...HASH_TRUNCATED...CA7F54A20F50000 | 4.3.1 | | 201203011745335_AutomaticMigration | 2012-03-01 17:45:33.557 | 0x1F8B08000000400ECBD07601C49...HASH_TRUNCATED...F4AE3681EF50000 | 4.3.1 | +------------------------------------+-------------------------+------------------------------------------------------------------+----------------+ 

Answer 1

According to your comment, it looks like the solution is straightforward. If you want to have the same timestamp, you should use Update-Database only once, and in your case this means using:

 Update-Database -Script 

and execute the created script in both databases.

In any case, I would probably not use automatic migrations in a scenario where I expect a downgrade. I would use code-based migration with an explicit name for each migration. In this case, each entry in the MigrationHistory table must have a unique name and timestamp, it does not matter.