Split EF Core migrations to multiple projects

Question

Is it possible to split (not moved to single class library project) migrations to several .NET Core class libraries?

I am following architecture design for splitting application to several independent modules. (Source)

But I having problems splitting migrations to several projects. Is this supported?

In startup I load dll files in specific folders. In DbContext.OnModelCreating I register all types loaded from loaded dll files and register entities.

 protected override void OnModelCreating(ModelBuilder modelBuilder)
        {
            List<Type> typeToRegisters = new List<Type>();
            foreach (var module in GlobalConfiguration.Modules)
            {
                typeToRegisters.AddRange(module.Assembly.DefinedTypes.Select(t => t.AsType()));
            }

            RegisterEntities(modelBuilder, typeToRegisters);

            base.OnModelCreating(modelBuilder);

            RegisterCustomMappings(modelBuilder, typeToRegisters);
        }

        private static void RegisterEntities(ModelBuilder modelBuilder, IEnumerable<Type> typeToRegisters)
        {
            var entityTypes = typeToRegisters.Where(x => x.GetTypeInfo().IsSubclassOf(typeof(EntityBase)) && !x.GetTypeInfo().IsAbstract);
            foreach (var type in entityTypes)
            {
                modelBuilder.Entity(type);
            }
        }

        private static void RegisterCustomMappings(ModelBuilder modelBuilder, IEnumerable<Type> typeToRegisters)
        {
            var customModelBuilderTypes = typeToRegisters.Where(x => typeof(ICustomModelBuilder).IsAssignableFrom(x));
            foreach (var builderType in customModelBuilderTypes)
            {
                if (builderType != null && builderType != typeof(ICustomModelBuilder))
                {
                    var builder = (ICustomModelBuilder)Activator.CreateInstance(builderType);
                    builder.Build(modelBuilder);
                }
            }
        }

But I don't how migrations are executed with context.Database.Migrate();

Idea is that tables are not created/updated if ASP.NET Core deployment doesn't include specific module. If at any point in the future, customer buys module D, I just send them dll. The next startup context.Database.Migrate(); would create all tables and apply migrations for that module.

Additional example:
Idea is to split application to modules. Let's say module A, B and C. Customer 1 buys module A and B and customer 2 buys module A and C.

There is no point that tables for module C are created for customer 1, and tables for module B for customer 2.

At some point in the future, customer 1 buys module C (they receive dll for module C). Now tables should create and all migrations for module C.

As far as I know migrations could be dedicated to specific project. Link. The only problem I see is the ContextModelShapshot.

Answer 1

All the Migration classes for a given DbContext need to be in the same assembly. To split them across different assemblies, you'll need separate DbContext classes.

You may find the Using a Separate EF Core Migrations Project doc page interesting.