36

I am facing a weird problem with code first migrations in Entity Framework version 5. Sometimes Update-Database fails due to pending changes but Add-Migration command only produces migrations with database changes already contained in the last migrations and the database is up-to-date. Therefore I'd expect the new migration to be empty.

How does Add-Migration detect what changes are due? It doesn't seem to use the database as a source.

Improve this question

1 Answer 1

Reset to default
61

A snapshot of the database model is saved along with every migration in a .resx file. When you add a new migration, EF compares the current database model (which is generated from your model classes and settings from your DbModelBuilder) with the last migration and determines a changes between them.

The problem you are describing can occur if your migrations are out of sync. It happens to us if two developers make two independent migrations and these migrations are later merged back to the default branch.

Example:

Developer 1

Migration AddColumnA

Developer 2

Migration AddColumnB

Merged version

Migration AddColumnA - database snapshot includes columnA

Migration AddColumnB - database snapshot includes columnB but not columnA

If you add another migration, the changes are determined against migration AddColumnB, that doesn't contain information about columnA. A workaround for this problem is to generate dummy migration (with empty Up and Down methods) just to have the correct database model snapshot in the last migration.

Merged version

Migration AddColumnA - database snapshot includes columnA

Migration AddColumnB - database snapshot includes columnB but not columnA

Migration Dummy - database snapshot with columnA and columnB

Improve this answer
Sign up to request clarification or add additional context in comments.

9 Comments

Very interesting. Is there a way to prevent that the migrations are created based on that resource file, so that the database is used as the reference? This is a serious drawback of the migrations in my opinion, as I really want to have EXPLICIT migration files instead of just the automatic migration but don't want to have numerous dummy migration files when working with multiple devs on the same codebase.
IMHO there isn't a way to specify database as the reference. Instead of creating dummy migration, you can update to the first migration (AddColumnA) and then regenerate the second migration. Up and Down methods will remain same but database snapshot will be updated to the correct version and dummy migration won't be necessary.
Thanks for all the information, but switching between revisions for each merge is a lot more of a hassle than having "ugly"/empty merge migration files. At least if you do one or more merges each day.
You will need to add a merge migration Add-Migration Merge –IgnoreChanges (for more details:msdn.microsoft.com/en-us/data/dn481501.aspx)
4 years later, and still having these problems. Sigh.
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.