相关疑难解决方法(0)

在开发我们的应用程序一段时间后，我们已经积累了相当多的 EFCore 数据库迁移。由于 EFCore 为每次迁移添加了整个 db 模型的快照，因此这段代码加起来相当多。经过分析，我们大约 80% 的编译时间都花在了迁移上（编译 + Roslyn 分析器）。

所以是时候清理一些旧的迁移了！但最好的方法是什么？好像没有官方的指导...

我们不需要任何回滚（我们只向前滚），所以这让事情变得更简单。我们确实需要支持从头开始创建数据库，并从最近几次迁移中更新数据库。

我试过的：

1. 核选项似乎是删除所有迁移和模型快照，并创建一个新的初始迁移。虽然这很好，但似乎有点危险。使用这种方法，我们需要非常小心，数据库模式的每个部分都是代码模型的一部分。例如，我们遇到的一种边缘情况是 EFCore 尚不支持检查约束。所以我们在迁移中添加了一个检查约束，而不是在代码模型中。因此，在创建新的初始迁移时，已检查的约束不是其中的一部分。

2. 作为实验，我尝试从所有旧迁移中删除模型快照，因为快照是导致编译时间过长的代码的 90%。我发现，EFCore 仅使用快照作为比较工具来进行新的迁移。删除快照后，旧的迁移在新数据库上运行时不再执行。

那么有没有更好的方法来完成我想要的？

我目前有一个efcore 2.1项目,包含大约230个实体和大约350个迁移.每次添加efcore迁移时,都会创建一个设计器文件.此文件大约为535 kb并且正在增长(对于alle设计器文件总计为150mb).这使得IDE缓慢且无响应,重构是不行的,它也使构建过程变慢.如果我删除所有设计器文件,则构建从110秒减少到20秒,IDE再次变得快速.

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

我之前也合并了所有迁移.这是有效的,除了在团队设置中有一些问题这样做(必须在每个开发人员机器上运行手动命令,没有团队成员可以进行任何未同步的迁移等)并且这只是暂时的,因为迁移在一段时间后再次开始堆积.

我很好奇是否有其他项目有同样的问题,以及他们如何解决这个问题？

我们有一个 .NET Core 项目，其中包含一个 Migrations 文件夹，其中包含多个迁移，我们过去可以通过执行 .NET Core 项目在开发数据库中成功运行这些迁移dotnet ef database update。但是，我们现在尝试将这些更改应用到我们的暂存数据库，但它不起作用。我们已将ASPNETCORE_ENVIRONMENT环境变量设置为Staging，当我们尝试运行迁移时，它似乎正确定位了暂存。我们的临时数据库中创建了一个dbo.__EFMigrationsHistory表，但其中没有条目。此外，当我们运行时dotnet ef migrations list，我们会收到一条消息“未找到迁移”。即使我们将ASPNETCORE_ENVIRONMENT变量设置回Development，我们也会得到相同的结果。

我们已经使用 verbose 标志运行了上述所有dotnet ef命令，并且没有收到任何错误。唯一看起来可能可疑的输出是No referenced design-time services were found和No design-time services were found，但我们无法确定需要做什么来解决这些问题。

当我们运行时dotnet ef migrations add <migration name>，它会在 Migrations 文件夹中成功生成一个迁移文件，并且当我们运行时dotnet ef migrations list会显示新的迁移，因此看起来我们的旧迁移位于正确的位置。dotnet ef只是由于某种原因他们没有被检测到。

我们的 中有以下软件包.csproj：

    <PackageReference Include="FlexLabs.EntityFrameworkCore.Upsert" Version="3.1.0" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="3.1.0">
      <IncludeAssets>runtime; build; native; …