entity-framework - 在显式迁移中捕获自动迁移的破坏性最小的方法？

Question

我有点难过。我继承了一个使用 EF 的项目，其中:

• 自动迁移最初是开启的
• 添加了一些自动迁移
• 添加了一些显式迁移
• 随后关闭了自动迁移

没有任何问题，因为部署此代码的机器已与开发机器并行移动，因此它们都有完整的工作数据库。

我担心的是，如果我们部署到另一台机器上，只会应用显式迁移。事实上，我发现在新的开发机器上运行项目时确实如此。

现在，我已经能够通过生成 SQL 创建脚本并在新机器上运行它们来哄骗它运行。显然，这不是一个长期的解决方案。

我可以看到的一个选项是清除所有迁移和迁移历史记录(在 __MigrationHistory 中)表并创建一个新的“初始”迁移，它将涵盖所有内容。我担心的是，我必须在每台运行代码的机器上执行此手术 - 包括生产服务器。

是否有任何方法可以追溯捕获初始自动迁移到新的显式迁移中，该迁移仅在全新的环境中运行？

Answer 1

如果您有能力手动更新您的数据库，您的一个选择是运行 Update-Database -Script .然后您将能够看到每个迁移(甚至是自动迁移)和 SQL 命令，因为它们将按顺序应用。继续并保存整个 SQL 文件，因为接下来的步骤将需要它。

接下来，查看将由 INSERT 分隔的每个命令 block 。命令包含一个巨大的 Base64 字符串。您会看到每个迁移步骤都被拆分并按顺序排列，包括自动迁移。对于这些对中的每一对，我们真的只需要 INSERT 以上的所有内容命令和 INSERT 下面最后一次迁移的命令。我将这些称为迁移操作。

当然，我意识到这将需要一些时间，但下次运行 Add-Migration -IgnoreChanges然后在 Up() 中构建一个空迁移方法添加一个新的 Sql()操作并将当前的迁移操作复制到其中(即 Sql("<your_awesome_script>") )。您可能需要制作相应的 Down()以及安全。

接下来，返回并查看您正在使用的自动迁移前后的迁移时间戳。这将在 INSERT 中命令作为第一个参数，例如 201710152132114_<MigrationName> .在这两者之间选择一个日期时间，然后将新迁移命名为 .cs使用该日期时间的文件。这将在您的解决方案中正确排序迁移以供将来使用。

最后打开迁移的.Designer.cs文件和内部 ImigrationMetadata.Id在 get 上替换现有的 Id将您创建的新迁移名称字符串化。这是 EF 将以编程方式使用的命令您的迁移操作。

如果移动到已经应用了一些迁移的新机器，请尝试查看它正在使用的数据库实例，并查看 __MigrationHistory 中最新条目的 ID 是什么表是。然后在您的开发环境中恢复针对那个迁移的迁移，并按照上面列出的每个自动步骤。如果您一次可以像这样转换所有自动迁移，那么将来您将能够部署到新环境中所有显式迁移。

我绝对建议不要在生产机器上尝试它，直到它在开发和测试环境中为您工作为止。