EF Core 9中DropTable与CreateTable组合操作的回归问题分析

在EF Core 9中，开发人员发现了一个重要的行为变化：当在同一个迁移中使用migrationBuilder.DropTable删除表后立即重新创建同名表时，会导致迁移失败并抛出KeyNotFoundException异常。这个问题在EF Core 8中并不存在，属于版本升级后出现的回归问题。

问题现象

当开发者编写如下迁移代码时：

protected override void Up(MigrationBuilder migrationBuilder)
{
    migrationBuilder.DropTable(name: "Employees");
    
    migrationBuilder.CreateTable(
        name: "Employees",
        columns: table => new
        {
            EmployeeId = table.Column<int>(type: "int", nullable: false)
                .Annotation("SqlServer:Identity", "1, 1"),
            Name = table.Column<string>(type: "nvarchar(max)", nullable: false)
        },
        constraints: table =>
        {
            table.PrimaryKey("PK_Employees", x => x.EmployeeId);
        });
}

执行迁移时会抛出异常：System.Collections.Generic.KeyNotFoundException: 'The given key '(Employees, )' was not present in the dictionary.'，堆栈跟踪显示问题发生在SQL Server迁移SQL生成器中。

临时解决方案

目前可行的临时解决方案是使用原始SQL命令替代DropTable方法：

migrationBuilder.Sql("DROP TABLE Employees;");

这种方式可以绕过EF Core内部的状态管理问题，使迁移能够成功执行。

问题背景与深入分析

这种Drop-Create模式在实际开发中有几个常见场景：

1. 表结构重大变更：当表需要完全重构而不仅仅是修改时
2. 解决EF Core生成无效迁移：有时EF Core生成的Alter操作无法正确执行，需要手动替换为Drop-Create
3. 开发过程中的重构：团队协作时可能需要手动调整迁移文件

EF Core 9中对临时表(temporal tables)处理机制的重新设计是导致此问题的根本原因。新版本在内部维护了一个字典来跟踪表的状态信息，当执行DropTable操作后，相关的状态信息被移除，但后续的CreateTable操作仍尝试访问这些信息，导致键不存在的异常。

官方修复计划

EF Core团队已经确认这是一个回归问题，并计划在以下版本中修复：

1. EF Core 10 Preview 3
2. EF Core 9.0.5

修复将包含两部分：

1. 使临时表信息字典的访问更加健壮（针对非临时表场景）
2. 对临时表处理机制进行全面重新设计（需要API变更）

最佳实践建议

在修复版本发布前，建议开发者：

1. 优先使用原始SQL命令进行表删除操作
2. 仔细审查自动生成的迁移文件，避免不必要的Drop-Create操作
3. 对于复杂表结构变更，考虑分多个迁移步骤执行
4. 在团队协作环境中，建立严格的迁移文件审查流程

这个问题提醒我们，在进行EF Core大版本升级时，需要全面测试所有迁移场景，特别是那些包含复杂表操作的部分。同时，了解框架内部机制有助于在遇到问题时更快找到解决方案。