如何处理巨大的 EF Core 迁移设计文件，以加快构建和 IDE 速度

Question

我目前有一个efcore 2.1项目，大约有230个实体和350个迁移。每次我添加efcore迁移时，都会创建一个设计器文件。该文件大小约为535kb，并且在增长中（所有设计器文件总计150MB）。这使得IDE变得缓慢和无响应，重构不可行，并且会使构建过程变慢。如果我删除所有设计器文件，则构建时间从110秒降至20秒，IDE再次变得敏捷。

然而，一旦我删除所有设计器文件，就无法使用“dotnet ef database”命令。

我之前也合并了所有的迁移，这个方法可以用，但在团队环境下有一些问题（必须在每台开发人员的计算机上运行手动命令，任何团队成员都不能有任何未同步的迁移等），而且这只是暂时的，因为迁移在一段时间后开始堆积。

我想知道是否有其他遇到同样问题的项目，以及它们如何解决此问题？

- Kim Hansen

---

我只看到一种解决方法：将上下文分成较小的部分，生成较小的迁移文件。拥有230个实体相当多。我对你的声明“重构不可行”感到好奇。你还有什么其他期望来改进这个问题吗？能否解释一下为什么不行？ - jpgrassi

我想表达的是重构很麻烦，因为集成开发环境太慢了。我可以理解那不是一个非常清晰的陈述 :) - Kim Hansen

Answer 1

未来，您可以向迁移文件夹添加一个.editorconfig文件，并包含以下内容：

# All files
# Sets generated code for all migrations
[*]
generated_code = true

这将禁用所有分析器，使得我的IDE在执行所有迁移时更加顺畅。

注意：需要Visual Studio 16.5版本。

- joakimriedel

---

嘿，这是被接受的答案，但对我似乎不起作用。我们将所有迁移放在一个单独的项目中，当构建此项目或整个解决方案时，VS倾向于花费很长时间，而MSBuild则需要大量资源。我已经添加了一个包含您代码的配置，但似乎没有任何区别。EntityFrameworkCore 2.2.4，Visual Studio 16.7.7。您有任何想法为什么它似乎不起作用吗？ - Gamingdevil

在EF Core中进行大规模迁移存在多个问题，这解决了代码分析器不必要地处理生成的代码的特定问题。也许你遇到了https://github.com/dotnet/efcore/issues/23435？我已经升级到.NET 5 / EF Core 5，不再遇到任何问题。 - joakimriedel

谢谢您的回复。不幸的是，我们目前无法升级，因为我们有超过几个客户评估查询会在EFCore 3中出现问题。然而，我们最大的设计文件仍然只有约600KB，远远没有您链接的问题中报告的2.5MB。我将尝试升级到16.8.2，这也是链接页面中推荐的版本。谢谢。 - Gamingdevil

更新：EF Core 5 使情况变得更糟。将 SDK 版本限制在 2.X 或 3.X 至少可以让我构建，但仍然非常缓慢和资源密集。如果我排除 .Designer 文件，则构建正常，但是 eftools 命令和实际迁移将不再起作用。 - Gamingdevil

你是用VS2019 16.8.2还是dotnet build来构建？因为后者尚未修补。请参见https://github.com/dotnet/roslyn/pull/48897以跟踪合并过程。 - joakimriedel

VS2019使用了大量的资源，但最终还是构建成功了。PowerShell使用dotnet工具时总是失败。不过，更新似乎没有解决我的初始问题，即由于大量迁移而导致资源密集型、缓慢的构建。这个问题又回到了起点。 - Gamingdevil

Answer 2

你可以使用其他程序集来管理迁移。

- Masud Safari

---

你能举个例子吗？ - Geomorillo

Answer 3

我认为你的问题是推荐清理旧的Entity Framework Core迁移和Entity Framework Core：如果我们永远不会还原迁移，删除Migration.Designer.cs是否安全？的重复。整个主题在这些帖子的各种答案中都有讨论。

我建议考虑我的答案，以使您的IDE再次敏捷并减少编译时间。从长远来看，将所有迁移定期合并为一个迁移似乎是一个好的做法。如果您的情况不紧急，您可能需要等待此功能（计划于.NET 6中）以更简单的方式执行此操作。

- Dejan

Answer 4

你可以尝试清除迁移文件。我有时使用它来保持数据模块的小巧和可编译性。你可能会发现这个链接很有用。

- Celal Ergün