Did you have any luck figuring this out? I've never tried this (by that, I mean I may be totally wrong here), but I wanted to give a reply that might help lead you in a direction to solving it, since no one else has replied yet. Maybe you could create different data layers/class libraries that are named according to the database you're using (to create unique namespaces and keep things organized), so your namespace for the unique DbContext file may end up being something like "namespace MyApplication.MyUniqueDataLayerName". I would create a folder like "Repository" within each of them to put all the CRUD logic in there for that particular database as well, plus your Migrations folders would go in each of them. And I imagine you'd want to separate and organize your Services/Interfaces in a way that makes them easy to find/use as well, since that could get confusing quickly.

When you add a new migration, just be sure to select the correct Data Layer in the drop down menu of Console Package Manager.

Then reference each of them accordingly in the ConfigureServices method in your Startup.cs file like:

// or something like MyApplication.MyUniqueDataLayerName.MyUniqueDbContext if you don't want to add using directives at the top of the page
services.AddDbContext<MyUniqueDbContext>(options =>
    options.UseSqlServer(
        Configuration.GetConnectionString("DefaultConnection")), ServiceLifetime.Transient);

The connection strings would be in your appsettings.json file.

If anyone has a better solution, please be sure to chime in.

Hi,

   Thanks for responding, I also posted this on the ASP.Net Core forum and had several responses. Conclusion, yes it is possible I have not tried it as yet as I am still in the early stages of development of my application but intend to do so. As you say the thing to do is to keep the models in separate folders and ensure you select the correct context.

Regards

Peter