Handling database migrations when using Entity Framework

We are building an app in C# which uses Entity Framework with SQL Server 2008. We design the model using the designer in Visual Studio and auto-generate entities from this.

We're working on version 1.0. When we release 2.0, we'll need to make changes to the model and underlying database structure. I guess we need what's called "database migrations".

Traditionally, I've had a table in the database called something like 'version'. Whenever I've created a new version of my software, I've created database upgrade scripts containing ALTER TABLE statements. My software has ch开发者_开发问答ecked the version table and run the upgrade scripts needed to upgrade the database to the 'software version'.

Is there some better way of handling this? It would be nice if I didn't have to write the alter table-scripts myself and write my own software to upgrade the database structure.

What I used to do when I did model first, is I pointed my model to a database that was purely for schema (so I had a myapp database, which was where my app ran, but my EF4 model was outputted to a myapp_schema database). When the myapp_schema was updated, I used Db Source Tools to generate the update scripts and make the myapp's database schema be the same as myapp_schema.

Chech this post out. It's about CTP4 of EF4, but it thing this is what you need.

http://blogs.msdn.com/b/efdesign/archive/2010/10/22/code-first-database-evolution-aka-migrations.aspx

Unforunately this isn't yet available. CTP5 was released a few days ago and as far as I know this is not yet included.