Our application has two contexts in the same application database. Each context is clearly divided into a separation of concerns.
Now it seems that if I have two contexts: Context1 and Context2, and if I change only the Context2 classes, EF 5.0 thinks that even Context1 has changed. This seems to confuse EF 5.0 and seems to cause migrations to and . After this incorrect detection, the resulting migrations are also incompatible. We are at a strange dead end due to this and our own supervision and, most likely, we must again rebuild the entire db :( (the paths up and down are inconsistent)
So the questions are:
- Does EF 5.0 support model change detection and migration for multiple contexts? I read this question about the EF 4.3 stack , as well as this MSFT post from Rowan , before considering this here. I don’t think this is a repeat since EF 4.3 => EF 5.0 improves the target code first and migration.
- If not, when do you guys (MSFT / Rowan!) Plan to support it?
thanks
Information about the history (you can skip):
We carefully select both schemes using the first api quick access code in the text, add test data and test it, and then add live data (alpha stages). Context1 received critical "live" information, so we left it untouched, and then changed the second context ( context2 here), adding a new member to the first class of code (new column in the table in terms of db). When I ran the application, it seemed to detect BOTH as modified! In the end, thinking that the immutable Context1 would not be called, we did not comment on Database.SetInitializer<Context1>(new DropCreateDatabaseIfModelChanges<Context1>()); we added during the climb. Thus, he destroyed our critical now growing tables! Yes, we had to do this, since simply closing the class definition was not enough.
source share