DropCreateDatabaseIfModelChanges EF6 results in System.InvalidOperationException: The model backing the context has changed

Question

After migrating to Entity Framework 6 I get an error when executing unit tests on the build server.

I'm using the DropCreateDatabaseIfModelChanges initializer. When I change it to MigrateDatabaseToLatestVersion everything works, but I want to stick with the former initializer.

The error I'm getting is:

System.InvalidOperationException: System.InvalidOperationException: The model backing the 'AppContext' context has changed since the database was created. Consider using Code First Migrations to update the database (http://go.microsoft.com/fwlink/?LinkId=238269)..

Which is correct, it changed, but with DropCreateDatabaseIfModelChanges initializer, it should be recreated. Any ideas?

EF is configured in App.config. Here's the relevant part:

<connectionStrings>
    <add name="AppContext" connectionString="Data Source=(localdb)\v11.0;Initial Catalog=my.app.unittest;Integrated Security=True" providerName="System.Data.SqlClient" />
</connectionStrings>
<entityFramework>
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
        <parameters>
            <parameter value="v11.0" />
        </parameters>
    </defaultConnectionFactory>
    <contexts>
        <context type="my.app.core.Data.AppContext, my.app.core">
            <databaseInitializer type="System.Data.Entity.DropCreateDatabaseIfModelChanges`1[[my.app.core.Data.AppContext, my.app.core]], EntityFramework" />
        </context>
    </contexts>
    <providers>
        <provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer" />
    </providers>
</entityFramework>

Answer 1

Well, it looks like EF 6.0 introduces a new rule:

"If the DbContext is using an Initializer AND Migrations are configured, throw an exception when building the model".

Up to and including the EF 6 RC this wasn't enforced. The annoying part is that "Migrations are configured" is defined by the implementation of a DbMigrationsConfiguration. There doesn't appear to be a way to programmatically disable Migrations in tests - if you implemented

I worked around it in a way very similar to Sebastian Piu - I had to get rid of the Configuration class from my tests, but I couldn't just remove it because we're using Migrations for our main project. Argh!

This was my code before:

public class MyDbContext : DbDContext, IMyDbContext
{
  public IDbSet<Users> Users {get; set;}
  public IDbSet<Widgets> Widgets {get; set;}
}

// Migrations are considered configured for MyDbContext because this class implementation exists.
internal sealed class Configuration : DbMigrationsConfiguration<MyDbContext>
{
  public Configuration()
  {
    AutomaticMigrationsEnabled = false;
  }
}

// Declaring (and elsewhere registering) this DB initializer of type MyDbContext - but a DbMigrationsConfiguration already exists for that type.
public class TestDatabaseInitializer : DropCreateDatabaseAlways<MyDbContext>
{
    protected override void Seed(MyDbContext context) { }
}

I encountered the System.InvalidOperationException when the DbContext was being initialized in my test code. Since the application doesn't use any Initializer, there were no problems running the app as before. This only broke my tests.

The solution (which feels more like a workaround to things missing from EF) is to segment the Initializer and DbMigrationsConfiguration so only one is seen in a runtime environment. I want my tests to use the Initializer and I want my application to use the DbMigrationsConfiguration. This could be done more cleanly if DbContext had an interface, but alas it only implements IObjectContextAdapter.

First I made my DbContext abstract:

public abstract class MyDbContextBase : DbContext, IMyDbContext
{
      public IDbSet<Users> Users {get; set;}
      public IDbSet<Widgets> Widgets {get; set;}
}

Then I derived 2 classes:

public class MyDbContext : MyDbContextBase
{
  public MyDbContext(string connectionStringOrName, IDatabaseInitializer<MyDbContext> dbInitializer) 
    : base(connectionStringOrName)
  {
  }
}

public class MyTestDbContext : MyDbContextBase
{
  public MyTestDbContext(string connectionStringOrName, IDatabaseInitializer<MyDbContext> dbInitializer) 
    : base(connectionStringOrName)
  {
    Database.SetInitializer(dbInitializer);
  }
}

Both a MyDbContext and a MyTestDbContext are IMyDbContexts, so your existing dependency injection setup should work without requiring changes. I only tested Spring.NET.

My DbMigrationsConfiguration implements the derived type that is NOT used by tests:

internal sealed class Configuration : DbMigrationsConfiguration<MyDbContext>
{
  public Configuration()
  {
    AutomaticMigrationsEnabled = false;
  }
}

Finally, the initializer's type was moved to the derived test class type:

public class TestDatabaseInitializer : DropCreateDatabaseAlways<MyTestDbContext>
{
    protected override void Seed(MyTestDbContext context) { }
}

I can confirm my tests are passing and my application (and Migrations) is still working as before.

Answer 2

I found the same issue just after upgrading to EF6. After reading Stefan´s comment and having the same symptoms as he describes (tests were loading the Configuration class from my main project)

Solution/workaround in my case was to

• create new class TestContext: MyDataContext in my Tests project
• change the initialiser from DropCreateDatabaseAlways<MyDataContext> to DropCreateDatabaseAlways<TestContext>
• update/generalise places where I created my real context to use the test one

I could do this because most of my tests just extend from a PersistenceTest class, so I understand this might be a pain to change if you have a big catalog. So looking forward to other solutions