在 EF 项目中，是否有设置 AutomaticMigrationsEnabled 的最佳实践？
更多声明：
在我们的团队中，在修改模型后，我们通常会在包管理器控制台中运行“add-migration”和“update-databse”命令。当其他开发人员运行该项目时会引发此错误：
“无法删除数据库，因为它正在使用中”
每次发生这种情况时，第一个修改器应该 Check In 整个项目，其他修改器必须 GET 修改的对象。在很多情况下，我们不想签入已经创建的模型和迁移！
这种情况很烦人，有没有解决这种问题的办法。 提前致谢。
【问题讨论】：
标签： entity-framework entity-framework-4 entity-framework-migrations
自动迁移为您提供了所有的魔法，但它们不允许严格的版本控制（您没有为每个版本设置特殊的固定迁移）。如果没有严格的版本控制，您将无法跟踪数据库的版本，也无法进行显式升级（根本无法进行降级）。
如果您不打算在需要知道数据库版本的地方使用版本控制，并且如果您不打算使用降级，则可以简单地使用自动迁移。
“无法删除数据库，因为它正在使用中”
看起来您正在处理共享数据库 = show stopper。每个开发人员都应该使用自己的数据库。
但不想签出已创建的模型和迁移！
这是一种最佳做法，如果您想继续进行基于代码的迁移，则必须遵循它。顺便提一句。有一种称为“持续集成”的做法 - 在持续集成中，您应该在提交成功构建并通过测试后立即get。
【讨论】：
Data Source 更改为本地计算机，每个开发人员都将拥有自己的同名数据库。后一种情况需要每个开发人员的连接字符串，因此您必须确保某些签入策略以避免将开发人员特定的连接字符串存储在源代码控制中。
发件人：http://msdn.microsoft.com/en-us/data/jj554735.aspx
团队环境建议
您可以穿插自动和基于代码的迁移，但这是 不建议在团队开发场景中使用。如果你是一个 使用源代码控制的开发人员团队，您应该使用 纯自动迁移或纯基于代码的迁移。鉴于 我们建议使用基于代码的自动迁移的限制 团队环境中的迁移。
【讨论】：