为什么 Add-Migration 有时会创建重复迁移？答案

【问题标题】：Why does Add-Migration sometimes create duplicate migrations?为什么 Add-Migration 有时会创建重复迁移？
【发布时间】：2013-10-08 18:52:24
【问题描述】：

我在 Entity Framework 版本 5 中遇到了一个奇怪的问题，即代码优先迁移。有时Update-Database 由于挂起的更改而失败，但Add-Migration 命令仅生成上次迁移中已包含数据库更改且数据库已启动的迁移-迄今为止。因此，我希望新的迁移是空的。

Add-Migration 如何检测到期的更改？它似乎没有使用数据库作为来源。

【问题讨论】：

【解决方案1】：

数据库模型的快照与每次迁移一起保存在 .resx 文件中。添加新迁移时，EF 会将当前数据库模型（由模型类和 DbModelBuilder 中的设置生成）与上次迁移进行比较，并确定它们之间的更改。

如果您的迁移不同步，则可能会出现您所描述的问题。如果两个开发人员进行了两次独立的迁移，并且这些迁移后来合并回默认分支，我们就会遇到这种情况。

例子：

开发者 1

迁移 AddColumnA

开发者 2

迁移添加列B

合并版

迁移 AddColumnA - 数据库快照包括 columnA

迁移 AddColumnB - 数据库快照包含 columnB 但不包含 A列

如果您添加另一个迁移，则根据迁移 AddColumnB 确定更改，该迁移不包含有关 columnA 的信息。此问题的解决方法是生成虚拟迁移（使用空的 Up 和 Down 方法），只是为了在上次迁移中获得正确的数据库模型快照。

合并版

迁移 AddColumnA - 数据库快照包括 columnA

迁移 AddColumnB - 数据库快照包含 columnB 但不包含 A列

Migration Dummy - 包含 columnA 和 columnB 的数据库快照

【讨论】：

非常有趣。有没有办法防止基于该资源文件创建迁移，以便将数据库用作参考？在我看来，这是迁移的一个严重缺点，因为我真的希望拥有 EXPLICIT 迁移文件，而不仅仅是自动迁移，但不希望在与多个开发人员在同一代码库上工作时拥有大量虚拟迁移文件。跨度>
恕我直言，没有办法将数据库指定为参考。您可以更新到第一个迁移 (AddColumnA)，然后重新生成第二个迁移，而不是创建虚拟迁移。 Up 和 Down 方法将保持不变，但数据库快照将更新为正确的版本，并且不需要虚拟迁移。
感谢所有信息，但是在每次合并的修订之间切换比拥有“丑陋”/空的合并迁移文件要麻烦得多。至少如果您每天进行一次或多次合并。
你需要添加一个合并迁移Add-Migration Merge –IgnoreChanges（更多详情：msdn.microsoft.com/en-us/data/dn481501.aspx）
4 年后，仍然存在这些问题。叹息。