如何在Code-First环境中禁用自动迁移并手动创建表/列？

问题根源 #

程序能正常运行但迁移报错，是因为项目的Migrations文件夹里存在迁移文件，但数据库的__EFMigrationsHistory表没有这些迁移的记录——大概率是之前的开发者手动修改了数据库，没同步迁移记录，或者生成了迁移但没执行。

第一步：确认迁移与数据库的状态 #

先在PMC里运行命令，查看哪些迁移已应用、哪些待处理：

Get-Migration

输出里带[Applied]的是已经同步到数据库的，剩下的就是报错里的待处理迁移。

第二步：安全处理待处理迁移 #

情况1：待处理迁移的操作已经在数据库里存在 #

打开每个待处理的迁移文件（比如202009221147053_wms.cs），看Up()方法的内容。如果里面的操作（比如新增表、加列）数据库里已经有了，直接标记这些迁移为已应用：

Update-Database -Migration 202010221446470_Transferencia

用最后一个待处理迁移的名称，EF只会把这些迁移的记录写入__EFMigrationsHistory，不会执行实际的数据库操作，之后就能正常生成新迁移。

情况2：待处理迁移的操作数据库里没有，且确认安全 #

如果Up()里都是新增类的操作（无删除、修改现有列的危险操作），直接执行同步：

Update-Database

EF会自动执行所有待处理迁移的Up()方法，同步数据库结构，不会破坏现有数据。

如果你坚持手动修改数据库 #

手动改库后必须同步EF的迁移记录，否则后续生成迁移会重复造轮子，步骤如下：

1. 手动在数据库里新增表/列，确保和项目中的实体类完全对应
2. 生成一个空迁移，让EF忽略当前模型与数据库的差异：

Add-Migration ManualSchemaUpdate -IgnoreChanges

这个迁移的Up()和Down()方法是空的，仅用于记录当前数据库状态
3. 执行迁移，把记录写入__EFMigrationsHistory：

Update-Database

之后生成新迁移时，EF就会以当前数据库结构为基准，不会重复生成你手动修改的内容。

注意：手动改数据库风险极高，容易出现实体类与数据库结构不一致，导致程序运行报错或后续迁移冲突，优先用Code-First的迁移机制管理结构变更。

内容的提问来源于stack exchange，提问作者Gustavo Heck