After migrating to Entity Framework 6 I get an error when executing unit tests on the build server.
I\'m using the DropCreateDatabaseIfModelChanges
initiali
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 {get; set;}
public IDbSet Widgets {get; set;}
}
// Migrations are considered configured for MyDbContext because this class implementation exists.
internal sealed class Configuration : DbMigrationsConfiguration
{
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
{
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 {get; set;}
public IDbSet Widgets {get; set;}
}
Then I derived 2 classes:
public class MyDbContext : MyDbContextBase
{
public MyDbContext(string connectionStringOrName, IDatabaseInitializer dbInitializer)
: base(connectionStringOrName)
{
}
}
public class MyTestDbContext : MyDbContextBase
{
public MyTestDbContext(string connectionStringOrName, IDatabaseInitializer 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
{
public Configuration()
{
AutomaticMigrationsEnabled = false;
}
}
Finally, the initializer's type was moved to the derived test class type:
public class TestDatabaseInitializer : DropCreateDatabaseAlways
{
protected override void Seed(MyTestDbContext context) { }
}
I can confirm my tests are passing and my application (and Migrations) is still working as before.