能否将EF Core迁移拆分至多个.NET Core类库？

你的需求完全可行——让每个模块独立维护自己的EF Core迁移，实现按需加载模块时自动执行对应迁移，同时解决ContextModelSnapshot的痛点。下面是一步步的具体实现方案：

一、每个模块独立管理自己的迁移 #

首先，给每个模块类库单独创建迁移文件，迁移目标指向你的主DbContext：

1. 进入模块类库的目录（比如./ModuleA），执行EF Core迁移命令：

dotnet ef migrations add ModuleA_Initial --context YourMainDbContext --project ./ModuleA --output-dir Migrations/ModuleA

• --context 指定你的主DbContext类型（创建迁移时需要主项目临时引用模块类库，发布时可移除该引用）
• --output-dir 把迁移文件生成在模块内部的Migrations/ModuleA文件夹，和模块代码打包在一起

2. 重复这个步骤给每个模块创建迁移，比如模块B的迁移命名为ModuleB_Initial，输出到ModuleB/Migrations/ModuleB。

二、动态加载模块的迁移文件 #

EF Core默认只会从主DbContext所在的程序集查找迁移，所以我们需要自定义迁移加载逻辑，让它扫描所有已加载的模块程序集：

1. 自定义IMigrationsAssembly实现 #

这个类负责从所有模块程序集中收集迁移类型：

using Microsoft.EntityFrameworkCore.Migrations;
using Microsoft.EntityFrameworkCore.Diagnostics;
using Microsoft.EntityFrameworkCore.Infrastructure;
using System.Reflection;

public class DynamicMigrationsAssembly : MigrationsAssembly
{
    private readonly IEnumerable<Assembly> _moduleAssemblies;

    public DynamicMigrationsAssembly(
        ICurrentDbContext currentContext,
        IDbContextOptions options,
        IMigrationsIdGenerator idGenerator,
        IDiagnosticsLogger<DbLoggerCategory.Migrations> logger,
        IEnumerable<Assembly> moduleAssemblies)
        : base(currentContext, options, idGenerator, logger)
    {
        _moduleAssemblies = moduleAssemblies;
    }

    public override IEnumerable<Type> GetMigrationTypes()
    {
        // 主程序集的核心迁移
        var coreMigrations = base.GetMigrationTypes();
        // 所有模块程序集中的迁移类
        var moduleMigrations = _moduleAssemblies
            .SelectMany(assembly => assembly.GetTypes())
            .Where(type => typeof(Migration).IsAssignableFrom(type) && !type.IsAbstract);

        // 合并并去重，确保不会重复执行迁移
        return coreMigrations.Concat(moduleMigrations).Distinct();
    }
}

2. 注册自定义迁移组件 #

在Startup/Program.cs中配置DbContext时，替换默认的IMigrationsAssembly，并传入所有加载的模块程序集：

var moduleAssemblies = GlobalConfiguration.Modules.Select(m => m.Assembly).ToList();
// 别忘了添加主DbContext所在的程序集
moduleAssemblies.Add(typeof(YourMainDbContext).Assembly);

services.AddDbContext<YourMainDbContext>(options =>
{
    options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection"))
           // 替换为自定义的迁移程序集
           .ReplaceService<IMigrationsAssembly>(sp => 
               new DynamicMigrationsAssembly(
                   sp.GetRequiredService<ICurrentDbContext>(),
                   sp.GetRequiredService<IDbContextOptions>(),
                   sp.GetRequiredService<IMigrationsIdGenerator>(),
                   sp.GetRequiredService<IDiagnosticsLogger<DbLoggerCategory.Migrations>>(),
                   moduleAssemblies));
});

三、解决ContextModelSnapshot的痛点 #

你担心的ContextModelSnapshot问题，核心是默认的Snapshot会在主项目中全局维护，导致模块迁移冲突。这里的解决方案是：

• 每个模块的迁移预先独立创建：模块的迁移文件已经包含了创建对应表的完整SQL逻辑，不需要依赖主项目的Snapshot。
• 可选：禁用主项目的自动Snapshot生成：如果主项目只有核心实体，可以在创建主项目迁移时加上--no-snapshot参数，避免Snapshot被模块迁移干扰：

dotnet ef migrations add CoreInitial --context YourMainDbContext --no-snapshot

• 确保模块迁移创建时，主DbContext已经包含该模块的实体（创建迁移时临时引用模块类库即可，发布时不需要主项目引用模块）。

四、执行迁移的逻辑 #

现在你只需要保留原有的context.Database.Migrate()调用即可：

using (var scope = app.Services.CreateScope())
{
    var context = scope.ServiceProvider.GetRequiredService<YourMainDbContext>();
    context.Database.Migrate();
}

当应用启动时：

1. 加载指定文件夹中的模块DLL（你的现有逻辑已经实现）
2. 动态注册模块的实体和映射（你的OnModelCreating代码已经处理）
3. Migrate()会自动发现所有模块中的迁移文件，执行那些尚未应用到数据库的迁移

五、测试你的场景 #

• 客户1（购买A+B）：部署时只包含模块A和B的DLL，启动后EF Core会执行ModuleA_Initial和ModuleB_Initial迁移，创建对应的表。
• 客户2（购买A+C）：部署时包含A和C的DLL，启动后执行ModuleA_Initial和ModuleC_Initial迁移。
• 客户1后续购买C：添加模块C的DLL后重启应用，EF Core检测到ModuleC_Initial尚未执行，自动创建C的表并执行迁移。

注意事项 #

• 迁移命名要唯一：建议用[模块名]_[迁移描述]的格式（比如ModuleA_AddUserTable），避免不同模块的迁移ID冲突。
• 迁移顺序控制：如果模块之间有依赖（比如模块C依赖模块A的表），可以通过迁移的时间戳ID来控制顺序，或者给迁移类添加自定义特性，在GetMigrationTypes()中排序。
• 模块版本兼容：每个模块的迁移要和模块版本绑定，避免旧版本模块的迁移和新版本主DbContext不兼容。

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