如何将.NET Framework中40个EF Migrations迁移至EF Core？

我完全懂你现在的处境——带着40个EF6迁移要转到EF Core，还要应付仓储重复、临时用Dapper凑数的麻烦，这事儿确实棘手。不过别慌，咱们一步步来解决：

1. 先把.NET Standard类库的EF Core环境捋顺 #

你已经搞定了IdentityDbContext和其他DbContext的移植，这是个好开头。现在要确保类库的EF Core工具链配置正确：

• 给类库装上必要的NuGet包：Microsoft.EntityFrameworkCore.Tools、Microsoft.EntityFrameworkCore.Design，还有你对应的数据库提供者（比如SqlServer就装Microsoft.EntityFrameworkCore.SqlServer）。
• 确保DbContext能正常连接现有数据库，模型和数据库结构完全匹配（字段、表名、索引、约束啥的都得对上）。

2. 处理40个历史迁移：两种选择 #

选择一：一键“固化”现有状态（推荐，省事儿） #

如果不需要保留这40个迁移的历史步骤，直接把当前数据库状态作为EF Core的起点就行：

1. 打开Package Manager Console（或者终端切换到类库目录），执行：

   Add-Migration InitialCreate -IgnoreChanges
   

   这个命令会生成一个空的初始迁移，-IgnoreChanges会让EF Core忽略模型和数据库的差异，只创建迁移的基础结构。
2. 接着执行Update-Database，把这个初始迁移记录到EF Core专属的__EFMigrationsHistory表中（和EF6的__MigrationHistory是分开的，不用担心冲突）。
3. 之后就可以正常用EF Core添加新迁移了，彻底和之前的EF6迁移解绑。

选择二：手动迁移历史记录（适合需要追溯变更的场景） #

如果你必须保留这40个迁移的历史步骤，就得逐个改造：

1. 把EF6的每个迁移文件（.cs和.designer.cs）复制到.NET Standard类库，修改命名空间匹配类库。
2. 手动替换API：
   • 把基类DbMigration改成EF Core的Migration。
   • 调整Up/Down方法里的数据库操作代码，比如EF6的CreateTable参数、索引创建语法，要换成EF Core的对应写法（大部分逻辑能复用，但细节得调整）。
3. 生成EF Core的模型快照：先执行Add-Migration TempMigration，然后把生成的快照内容替换成EF6所有迁移执行后的模型状态，再删掉这个临时迁移。
4. 按顺序执行Update-Database，让EF Core把这些改造后的迁移记录到__EFMigrationsHistory里。

• 提醒：这个方法工作量大，容易踩坑，除非业务必须要保留历史，否则优先选第一种。

3. 解决仓储重复的问题 #

既然DbContext已经统一到.NET Standard类库，那仓储也可以跟着统一：

• 把仓储实现都移到这个类库中，让.NET Framework和.NET Core应用都引用它。
• 给.NET Framework应用装上EF Core的兼容包，这样它就能直接用类库中的EF Core DbContext和仓储，不用再维护EF6版本的仓储了。
• 逐步淘汰原来的EF6仓储实现，这样就不用再靠Dapper规避冲突，代码也不会重复了。

4. 几个关键注意点 #

• 数据库兼容性：EF6和EF Core生成的SQL有细节差异（比如字符串长度、默认值、索引命名），迁移后一定要测试所有数据库操作是否正常。
• 身份验证测试：IdentityDbContext移植后，要验证用户登录、角色权限这些功能是否正常，确保身份数据没出问题。
• 增量迁移同步：如果移植期间还有新的EF6迁移生成，要及时同步到EF Core，或者干脆直接切换到EF Core管理所有新变更。

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