Entity framework 如何处理正在减慢构建和IDE速度的大型efcore迁移设计器文件

我目前有一个efcore 2.1项目，包含大约230个实体和大约350个迁移。每次添加efcore迁移时，都会创建一个设计器文件。该文件大约535 kb，并且还在增长（alle designer文件的总容量为150 MB）。这会使IDE变得缓慢且无响应，重构是不可能的，它也会使构建过程变慢。如果我删除所有设计器文件，构建时间将从110秒减少到20秒，IDE将再次快速运行

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

我以前还合并了所有迁移。这是可行的，除了在团队设置中存在一些问题（必须在每个开发人员机器上运行手动命令，任何团队成员都不能进行任何非同步迁移等），而且这只是暂时的，因为迁移在一段时间后再次开始堆积

---

我很好奇是否还有其他项目存在同样的问题，以及它们是如何解决这个问题的

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

现在，将来，您可以将一个

.editorconfig

文件添加到migrations文件夹中，其中包含以下内容：

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

它将禁用所有分析器，这使我的IDE在所有迁移中都更加愉快

---

注意：需要Visual Studio 16.5，您可以尝试清除迁移文件。我有时使用它来保持数据模块的小型化和可编译性。你可以找到有用的东西。

我认为你的问题是和的重复。关于这些主题的各种回答中讨论了整个主题

---

我建议考虑一下我的问题，以便重新得到你的IDE，减少编译时间。从长远来看，不时地将所有迁移汇总到一个迁移中似乎是一种好的做法。如果您的情况不紧急，您可能需要等待（针对.NET 6的计划），以便以更简单的方式执行此操作。

我只看到一种解决方法：将上下文划分为更小的上下文，生成更小的迁移文件。拥有230个实体相当多。我对你的说法很感兴趣：“重构是不可能的”。您还希望如何改进这一点？我想说的是重构是一种痛苦，因为IDE太慢了。我可以看出这不是一个很清楚的说法：）嘿，这是公认的答案，但似乎对我不起作用。我们将所有迁移都放在一个单独的项目中，在构建此项目或整个解决方案时，VS往往需要很长的时间，而MSBuild需要大量的资源。我在你的代码中添加了一个配置，但似乎没有任何区别。EntityFrameworkCore 2.2.4，Visual Studio 16.7.7。你知道为什么它看起来不起作用吗？EF Core中的大量迁移存在多个问题，这解决了代码分析器不必要地处理生成的代码的特殊问题。也许你在打？我已升级到.NET 5/EF Core 5，不再遇到任何问题。谢谢您的回复。不幸的是，我们目前无法负担升级费用，因为我们有超过几个客户端评估的查询，这些查询将在EFCore 3中中断。但是，我们最大的设计器文件仍然只有大约600KB，因此与您链接的问题中报告的2.5MB相差甚远。我将尝试升级到16.8.2，这也是链接页面中推荐的。谢谢。更新：EF Core 5让情况更糟。将sdk版本限制为2.X或3.X至少可以让我进行构建，但它仍然非常缓慢，而且需要大量资源。如果排除.Designer文件，则生成是正常的，但eftools命令和实际迁移不再起作用。您是使用VS2019 16.8.2还是使用dotnet生成？因为后者尚未修补。请参阅以跟踪合并进程