Note: this is only applicable for EF versions less than or equal to six. Version seven (part of .NET Core) has a completely different migration strategy.
EF code-first migrations are an easy way to keep your domain models and database schemas synchronized. However, if you ever decide to refactor your migration namespace, then remember this piece of wisdom: the migration history table stores migration-file namespaces as a column-value. For a quick refresher, here is the schema and sample dataset:
For our sample, assume the pictured migration-file created a new table called
Cars. Further, let us assume I refactor the namespace in the migration-file to
Better.Namespace.Migrations. When I run the app., the following exception is thrown:
SqlException: There is already an object named 'Cars' in the database.. This is due, in part, to the migration runner looking in the history table and trying to match
ContextKey with migration filenames and namespaces. It cannot find a match, so it thinks it needs to run our refactored file again. To fix this problem, we just need to update
ContextKey for the
MigrationId row matching our migration filename:
update [__MigrationHistory] set [ContextKey] = 'Better.Namespace.Migrations' where [MigrationId] = '201408121529377_initial_migration';
Restart the app. and we are back in business.