My Seed() method is never called in Code First EF 5

Question

My Seed() method is never called. It is called when I do an Update-Database from the Package Manager Console, but never when I run from code. If I delete my database, all tables are created ( so my migration classes are executed), but my Seed() code is never called. MVC 4, Entity Frame Work 5 Code First.

Global.asax:

protected void Application_Start()
{
  Database.SetInitializer<MyContext>(new DbInitializer());
}

DBInit:

internal class DbInitializer : MigrateDatabaseToLatestVersion<MyContext, Migrations.Configuration>
{
}

DBContext:

public partial class MyContext : DbContext
{
  public MyContext() : base("DefaultConnection")
  {
  }
  // public DBSets....
}

Configuration:

internal sealed class Configuration : DbMigrationsConfiguration<MyContext>
{
public Configuration()
{
  // The constructor is actually called
  AutomaticMigrationsEnabled = false;
}

protected override void Seed(MyContext context)
{
   // My seed code, never called
}

What could be wrong?

Shoeblack

Are you sure that you are doing something with the context? DbContext is lazy; it doesn't do much of anything until you start using it by, for example, running a query or adding an object. Your initializer will only run when the context is used for the first time. You can cause initialization to happen by calling context.Database.Initialize(false); – Textualist

I have the same issue, although i don't have quite the same configuration (I am relying on the out of box experience).I tried running context.database.Initialize(false) with both true and false but neither of them caused the seed method to run. – Teatime

@ArthurVickers Yes, I'm sure. – Shoeblack

Answer 1

So the reason was that I needed to specify my custom Initializer in the config file:

  <entityFramework>
      <contexts>
        <context type="EFTest2.MyContext, EFTest2">
          <databaseInitializer type="EFTest2.Initializers.DbInitializer, EFTest2" />
        </context>
      </contexts>
      <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" />
  </entityFramework>

After that, my Seed method is called.

Shoeblack

Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyContext, MyDbMigrationsConfiguration>()); /* in your context constructor also works */ – Supposition

Answer 2

Please first refer to the accepted answer.
I just want to add a very important note to this issue.

I was facing EXACTLY the same problem which described by this question (and this lead me to here). BUT I was using CreateDatabaseIfNotExists instead of MigrateDatabaseToLatestVersion and my seed method was not executed even after applying the accepted answer.

My problem was the following : According to the documentation of the for the Seed method : the Seed method of the DbMigrationsConfiguration will not be executed if the Database Initializer is one of the following

• DropCreateDatabaseAlways
• DropCreateDatabaseIfModelChanges
• CreateDatabaseIfNotExists

If you are using one of those types, you should create your own class which inherits from one of those types, and then override the seed method in your own class.

In my case, adding the following class solved the problem.

public class CreateNotifierDatabaseIfNotExists : CreateDatabaseIfNotExists<NotifierContext>
{
    protected override void Seed(NotifierContext context)
    {
        // the code of the seeding is go here
    }
}

Loper

Here's what I'm not understanding: When would you not use one of these classes? I had been following an example in a book which stated out using DropCreateDatabaseIfModelChanges which created my database, and then later changed it to a NullDatabaseInitializer and a DbMigrationsConfiguration for seeding. It all worked fine on my end but now I'm finding out the database is not being created for other developers. So I changed it to CreateDatabaseIfNotExists and now it creates, but doesn't seed. So is DbMigrationsConfiguration only intended for use against a db not created by EF? – Dilisio

Answer 3

In my experience, this can happen when you stop trying to access DataContext. We had a method that was throwing errors when DataContext was finished creating the DataBase. We commented it out in order to resolve the problems with DataBase creation.

The problem was, this was the only method that actually used DataContext on initial loading. That meant that no DbInitialization logic executed, because an instance wasn't yet required.

When we added a less-problematic data retrieval logic instead of the commented-out one, the DbCreation and Seeding logic took place as normal.

Iciness