In EF projects, Is there any best practice for setting AutomaticMigrationsEnabled ?
More declaration:
In our team after modifying a model we usually run "add-migration" and "update-databse" commands in Package Manager Console. This error raises when other developers run the project:
"Can not drop database because it is in use"
Every time this happen the first modifier should Check In
whole project and others have to GET
modified objects. In many cases we don't want to check in the already created model and migration!
This situation is annoying,are there any solution for this kind of problems.
thanks in advance.
Automatic migrations do all the magic for you but they don't allow strict versioning (you don't have special fixed migration for each version). Without strict versioning you cannot track version of your database and you cannot do explicit upgrades (you cannot do downgrades at all).
If you don't plan to use versioning where you need to know what version the database is and if you don't plan to use downgrading you can simply use automatic migration.
"Can not drop database because it is in use"
It looks like you are working on the shared database = show stopper. Each developer should use his own database.
but don't want to checkout the model and migration that was already created!
That is a best practice and if you want to continue with code based migrations you will have to follow it. Btw. there is a practice called "continuous integration" - in continuous integration you should get immediately after the commit is successfully built and passes tests.
From: http://msdn.microsoft.com/en-us/data/jj554735.aspx
Recommendation for Team Environments
You can intersperse automatic and code-based migrations but this is
not recommended in team development scenarios. If you are part of a
team of developers that use source control you should either use
purely automatic migrations or purely code-based migrations. Given the
limitations of automatic migrations we recommend using code-based
migrations in team environments.