title: Entity Framework 5 Migrations: Setting up an initial migration and single seed of the database
body: <p>I have an MVC4 app which I've recently upgraded to Entity Framework 5 and I am trying to move our database over to using migrations from the development style of dropping and creating each run.</p>
  
  <p>Here's what I've done in my app start function.</p>
  
  <pre><code>protected void Application_Start()
  {
      Database.SetInitializer(
          new MigrateDatabaseToLatestVersion&lt; MyContext, Configuration &gt;() );
      ...
  }
  </code></pre>
  
  <p>I ran the <code>Enable-Migrations</code> command on my repositories project and I thought that this would create an initial migration file however the only file it created was <code>Configuration</code></p>
  
  <p>When I delete the database it creates it as expected via code first and seeds the database from the Configuration file.  In the configuration file I changed all the <code>Add()</code> functions to <code>AddOrUpdate()</code></p>
  
  <p>However it runs the seed function in my <code>Configuration</code> file each time the website starts and duplicates all the seed data again and again.</p>
  
  <p>I imagined that it would create an <code>initial migration</code> file as the blog I read suggested that it would and I could put the seed data in there but it didn't</p>
  
  <p>Can anyone explain how I should be setting up DB in code so that it only seeds once?</p>
  
  <hr>
  
  <p><a href="http://weblogs.asp.net/dotnetstories/archive/2012/11/20/looking-into-entity-framework-code-first-migrations.aspx" rel="noreferrer">LINK: The migrations blog post I followed</a></p>
  
  <hr>
  
  <p>While this is quite interesting for using the EF migrate.exe I've since switched to using <a href="https://github.com/chucknorris/roundhouse" rel="noreferrer">roundhouse</a> for running migrations.  I still use EF to scaffold my migrations based on the models but I wrote a little console app to write the migrations out to SQL files.  I then use roundhouse to perform the migrations themselves through my rake build scripts.  There's a little more process involved but it's much more stable than using EF to perform the migrations on the fly when the application starts up.</p>