I only have 2 days experience with EF Migrations, so please be kind ...
I have a pretty big existing WPF WCF MVVM EF 4.1 solution that needs to be migrated to EF 4.3.1 and start using Migrations. The Services project contains four DbContexts, each in its own namespace and each associated with its own database.
Before I started modifying the big solution, I did a few experiments with a small console application example with one project and two DbContexts, mainly with the example presented by "e10" ( EF 4.3 Automatically moving with several DbContexts in one database ). The sample application works well, and I can do add-migration and update-database separately for two contexts (by specifying the -configuration parameter).
But when I tried to reproduce the same approach with a “real” (large) solution - with four DbContexts - I ran into a problem: when I call add-migration in PMC and specify any of the four configuration names, add -migrations gets an exception, saying that he cannot load the Services assembly.
Here is what I did with a great solution:
1) Added the EF 4.3.1 NuGet package to my Core, Services and UI projects (this last bit may be important).
2) created the Migrations folder in my Services project and manually created a Configuration.cs file containing four classes that inherit from DbMigrationsConfiguration <type>, where type is App, Catalog, PortfolioManagement or Scheduler. (code below)
3) a property has been added for one of the model classes associated with the App DbContext, so there would be something to migrate
4) from PMC, add-migration is called:
PM> add-migration App_AddNewProperty -config App
Note that I did not do “Enable-Migrations” because, as e10 said in his post:
"You do not need to enable migration, as you have already done this with ... the classes above" (referring to the classes in Configurations.cs).
5) add-migration receives an exception: failed to load the file or assembly "MyApp.Services" or one of its dependencies
I turned on bind logging and the crash log shows that it is trying to find the service assembly in the buffer / debug folder of the user interface , not in the Services project).
And it fails in the same way, even if I have a default project in PMC set for the Services project (by default, the project corresponds to the user interface project).
I suspect this is because the user interface does not have a link to the service assembly (it has a link to the WCF service, but not a link to the assembly). But if this is a problem, how can I prevent PMC from starting in the user interface project? Or can I "disconnect the user interface project from the EF package"?
Thanks!
Dadcat
Configurations.cs:
namespace MyApp.Services.Migrations { internal sealed class App : DbMigrationsConfiguration<Geophysical.Skimmer.Services.App.Repository.ModelContainer> { public App() { AutomaticMigrationsEnabled = false; MigrationsNamespace = "MyApp.Services.App.Repository.ModelContainer"; } protected override void Seed(MyApp.Services.App.Repository.ModelContainer context) { ... no code here } } internal sealed class Catalog : DbMigrationsConfiguration<Geophysical.Skimmer.Services.Catalog.Repository.ModelContainer> { public Catalog() { AutomaticMigrationsEnabled = false; MigrationsNamespace = "MyApp.Catalog.Repository.ModelContainer"; } protected override void Seed(MyApp.Services.Catalog.Repository.ModelContainer context) { ... no code here } } internal sealed class PortfolioManagement : DbMigrationsConfiguration<Geophysical.Skimmer.Services.PortfolioManagement.Repository.ModelContainer> { public PortfolioManagement() { AutomaticMigrationsEnabled = false; MigrationsNamespace = "MyApp.PortfolioManagement.Repository.ModelContainer"; } protected override void Seed(MyApp.Services.PortfolioManagement.Repository.ModelContainer context) { ... no code here } } internal sealed class Scheduler : DbMigrationsConfiguration<Geophysical.Skimmer.Services.Scheduler.Repository.ModelContainer> { public Scheduler() { AutomaticMigrationsEnabled = false; MigrationsNamespace = "MyApp.Services.Scheduler.Repository.ModelContainer"; } protected override void Seed(MyApp.Services.Scheduler.Repository.ModelContainer context) { ... no code here } } }