There is an unsaved comment in progress. You will lose your changes if you continue. Are you sure you want to reopen the work item?

1

Closed

EF5 Migrations - Multiple Developers

description

We have an issue where the following occurs when using code first and scaffolded migrations.

1 - Developer A adds class ClassA and scaffolds the migration
2 - Developer B adds class ClassB and scaffolds the migration (without having developer A's changes as they have yet to be added to source control)
3 - Developer A commits to source control and updates to top copy
4 - Developer B commits to source control and updates to top copy

We now have the following problem:
1 - Developer A is now being told that "Unable to update database to match the current model because there are pending changes and automatic migration is disabled."
2 - Developer B is missing the table that Developer A added and migrations thinks he is up to date.

The reason is because the model is stored with the migration and the later migration was created without having Developer A's model changes. If Developer A now does Add-Migration he will get a new migration with the same changes in as he previously created!

This seems quite a fundamental issue in a multi-developer environment.

Cheers
Chris

file attachments

comments

This can typically be handled by using the "re-scaffolding" feature, which is a way of updating the code-behind metadata of an existing migration. The way you re-scaffold is by running Add-Migration and passing the name of an existing migration. Migrations
will then overwrite the code-behind metadata with the latest model.

Here's how it would work for the scenario you describe:

1 - Developer A adds and runs migration A locally.
2 - Developer B adds and runs migration B locally.
3 - Developer A commits to source control.
4 - Developer B is ready to commit and so gets latest from the repo.
5 - Developer B sees that a new, earlier migration (migration A) now exists and so migration B needs to be re-scaffolded.
6- Developer B reverts migration B locally by using the TargetMigration argument and pointing to the local migration occurring before migration B (or $InitialDatabase to undo all applied migrations). NB. This step is only required if developer B has actually
applied migration B.
7) Developer B re-scaffolds migration B and runs Update-Database - Migrations A & B are applied.
8) Developer B commits. Migration B now has the correct metadata and so developer A is able to simply pull and run Update-Database.