When you use the Entity Framework Code First approach to build your database, EF’s default behavior is to verify if a database exists when the application runs the first time. In case it does not exist, EF creates it.

There might exist some situations when there is no need to run this initialization logic, e.g. when you run unit tests on an existing database.

Disabling the initialization for a given context type is really simple. This call will do the job:

System.Data.Entity.Database.SetInitializer<TContext>(null);

I found a sample on Stack Overflow where a custom System.Data.Entity.IDatabaseInitializer<TContext> was implemented, having an empty InitializeDatabase method. But why create and maintain a class when we can get the same result for free.

Setting the initializer to null should be performed before the database is accessed the first time by the context type. I prefer to put this into the initialization method of my application or inside of the TestInitialize method of my unit test classes. Putting this code into the ctor of the DbContext class will lead to an unneeded number of calls every time an instance of the context class is created.

And because I forgot to do so, an additional hint concerning the unit tests: It is not sufficient to disable the initialization logic for the DbContext type defined / used in the test project. Also, the initializer of the DbContext type used by the application classes, defined in the application project, has to be set to null.

Links

Understanding Database Initializers in Entity Framework Code First