EF 6.1.3 Code First自动迁移失败 求助根因排查与解决

我之前处理过不少EF自动迁移的问题，结合你描述的情况——清空数据库能正常创建、排除Seed方法问题，咱们一步步来梳理排查思路和解决办法：

一、根因排查步骤 #

• 检查__MigrationHistory表的完整性
  自动迁移完全依赖这个系统表跟踪模型与数据库的匹配度。如果表记录被篡改、删除，或者表里存储的模型哈希值和当前程序的实体模型哈希不匹配，EF就会无法识别变更直接报错。你可以查看这张表的Model列（二进制数据），对比当前程序集生成的模型哈希（可通过DbContext.ModelBuilder.Build().Hash获取，或用反编译工具查看编译后的模型元数据）。
• 验证发布程序集的一致性
  很多问题出在发布服务器残留旧版本实体类DLL，或者EF版本冲突（比如引用了多个版本的EntityFramework.dll）。先清理发布目录，重新部署最新程序包，确保所有依赖的EF组件都是6.1.3版本。
• 确认数据库权限
  发布账号可能没有足够的数据库操作权限，比如无法修改__MigrationHistory表、无法创建/修改表结构。可以测试用该账号手动执行ALTER TABLE等操作，验证权限是否充足。
• 排查模型变更的兼容性
  EF自动迁移对一些破坏性变更支持不佳，比如重命名列、修改主键类型、删除表后重建同名表，这类操作会导致模型对比逻辑混乱。回忆下最近的实体类变更，有没有这类操作？
• 开启EF详细日志
  在你的DbContext构造函数里添加日志输出，能直接看到迁移过程的错误细节：

  public YourDbContext() : base("YourConnectionString")
  {
      // 开发环境输出到调试窗口
      Database.Log = s => System.Diagnostics.Debug.WriteLine(s);
      // 发布环境可输出到日志文件
      // Database.Log = s => System.IO.File.AppendAllText("ef_migration_log.txt", s);
  }
  

二、针对性解决方法 #

• 修复__MigrationHistory表问题
  • 若表记录已损坏，备份数据后删除__MigrationHistory表，重新运行自动迁移（EF会重建所有表并生成新迁移记录）；
  • 不想清空数据的话，生成显式迁移：在Package Manager Console执行Add-Migration TempMigration，EF会生成模型与数据库的差异脚本，再执行Update-Database同步，之后可删除临时迁移文件。
• 解决程序集冲突
  • 在NuGet包管理器里统一所有项目的EF版本为6.1.3，清理本地和服务器的bin/obj目录后重新编译部署；
  • 检查发布服务器GAC里是否有旧版本EF组件，如有先卸载。
• 调整数据库权限
  给执行迁移的账号授予ALTER、CREATE TABLE、INSERT（针对__MigrationHistory表）等必要权限，或改用拥有DB Owner权限的账号执行迁移。
• 处理不兼容的模型变更
  对于自动迁移无法处理的变更，先手动编写SQL脚本完成数据库修改，再执行Add-Migration SkipMigration -IgnoreChanges生成空迁移记录，更新到数据库让EF认为模型与数据库已同步。

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