title: EF 5 code-first migrations with multiple contexts?
body: <p>Our application has two contexts into the same application database. Each context is cleanly divided across their separation of concerns.</p>
  
  <p>Now it seems that if I have two contexts, Context1 and Context2 and if I only change Context2's classes, EF 5.0 thinks even Context1 has changed. That seems to confuse EF 5.0 and seems to trigger migrations on <strong><em>both</em></strong>. After that incorrect detection, the resulting migrations are also inconsistent. We at a weird dead end due to that and our own oversight and most likely have to rebuild the entire db all over again :( (the up and down paths are inconsistent)</p>
  
  <p>So, <strong><em>questions:</em></strong></p>
  
  <ol>
  <li>Does EF 5.0 support model-change detection and migrations for multiple contexts? I read <a href="https://stackoverflow.com/questions/9110536/ef-4-3-auto-migrations-with-multiple-dbcontexts-in-one-database" title="this EF 4.3 stackoverflow question">this EF 4.3 stackoverflow question</a> and also <a href="http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/7980871d-0271-47dc-8185-43fdcbeea57f" rel="nofollow noreferrer" title="this post">this MSFT post by Rowan</a> before considering asking this here. I don't think this is a repeat since EF 4.3 => EF 5.0 improvements target code-first and migrations.</li>
  <li>If not, when are you guys (MSFT/Rowan!) planning to support it?</li>
  </ol>
  
  <p>Thx</p>
  
  <p><em>Background story details (can be skipped):</em></p>
  
  <p>We carefully set both 'schemas' via with code-first fluent api, added test data, tested it out and then added 'live' (alpha stage) data. Context1 bore critical 'live' info so we left it untouched and I then modified the 2nd context (<code>context2</code> here) by adding a new member to the code first class (new column in table in db terms). When I ran the app, it seems to have detected BOTH as changed! At our end, thinking the unchanged Context1 won't be called, we didn't comment out the 
  <code>Database.SetInitializer&lt;Context1&gt;(new DropCreateDatabaseIfModelChanges&lt;Context1&gt;());</code> we added during bringup. So it wiped out our critical now-grown tables! Yes, we should have taken it out as simply locking down the class definition wasn't good enough.</p>