Entity Framework Core迁移脚本生成器在DevOps流水线执行旧迁移报错

根因定位 #

你遇到的报错核心差异是本地Update-Database执行逻辑与Azure DevOps流水线生成的迁移脚本执行逻辑不一致，可按以下步骤排查：

• 验证迁移脚本生成逻辑差异：本地Update-Database默认仅执行当前数据库未应用的增量迁移，而Azure DevOps的Entity Framework Core Migrations Script Generator任务如果未配置增量参数，会默认生成从初始迁移到最新版本的全量脚本。如果你的列重命名操作没有使用EF官方的RenameColumnAPI，而是生成了「删除旧列+新增新列」的迁移，或者旧迁移中存在引用旧列的索引、约束定义，全量脚本执行时扫描到旧迁移的旧列引用就会抛出无效列错误。
• 本地复现验证：在项目根目录执行以下命令，生成和流水线逻辑一致的全量幂等脚本，直接在目标Azure SQL库执行，确认是否复现报错：
  dotnet ef migrations script --output full_migrate.sql --idempotent
• 检查ASPNETZERO默认逻辑冲突：ASPNETZERO框架默认开启应用启动时自动执行迁移的配置，如果你的流水线同时配置了「独立SQL迁移步骤」+「保留应用启动自动迁移」，两边执行时序冲突也会触发报错：比如应用启动先执行了删除旧列的迁移，后续流水线的迁移脚本还在引用旧列名。

解决方案 #

根据定位结果选择对应修复方案：

• 若为全量脚本生成问题：
  1. 调整Azure DevOps迁移生成任务参数，开启「Idempotent（幂等）」选项，同时指定From参数为上次成功部署的迁移ID，仅生成增量迁移脚本，避免扫描旧迁移的无效列引用。
  2. 手动修正列重命名对应的迁移文件，将自动生成的AddColumn+DropColumn逻辑替换为官方重命名API：

  migrationBuilder.RenameColumn(
      name: "OldColumn名",
      table: "对应表名",
      newName: "NewColumn名");
  

• 若为双迁移逻辑冲突：
  二选一关停其中一套迁移逻辑即可：要么修改YourProjectNameEntityFrameworkCoreModule配置，关闭框架启动自动迁移：Configuration.Modules.AbpEfCore().RunDbMigrations = false;，仅走流水线迁移步骤；要么关闭流水线的独立SQL迁移执行步骤，仅保留应用启动自动迁移。
• 紧急验证方案：可将本地Update-Database执行成功后生成的SQL脚本导出，直接替换流水线生成的脚本执行，排除连接串权限、账号配置类基础问题。

验证修复 #

修改后首次运行流水线时，建议开启Release调试模式，先输出生成的迁移脚本内容，确认无旧列名引用后再执行正式部署。

内容的提问来源于stack exchange，提问作者Kevin Bennett