A couple of weeks ago we released Alpha 2 of Code First Migrations. Today we are happy to make Alpha 3 available to you.

The overall feedback we got on Alpha 2 was that you like the direction we are headed. We heard that there is definitely a use case for automatic migrations, and while not everyone will use them, we should continue to invest in them. You are asking us to look at the story for data migration that doesn’t involve dropping down to SQL. Alpha 2 also had some commonly encountered bugs that were annoying and we needed to fix

Alpha 3 is still is primarily focused on the developer experience inside of Visual Studio. This release adds most of development time features we plan to include in the first RTM. Your feedback will guide any changes we make to the overall design. Apart from responding to your feedback our team is starting to focus on improving quality. We are also working on completing the deployment and team-build stories, including a command line tool and an MSDeploy provider.

What Changed

Alpha 3 is focused on adding the remaining features that you have been asking for around development time migrations. The primary changes in Alpha 3 are:

VB.NET migration generation is now available.

Upgrade/Downgrade to any migration is now available via the –TargetMigration switch.

Seed data can now be added by overriding the Seed method of the Settings class. Data is expressed in terms of the current model and the Seed method is called after upgrading to the latest migration.

We removed TargetDatabase from the Settings class. Instead you can use the –TargetDatabase switch to specify the name of a connection string from your App/Web.config file.

You can now start using Code First Migrations against an existing database that was created by Code First. To do this issue an Update-Database command when you model is the same as the model that created the database. To use this feature the EdmMetadata table must be present in the database. This original creation of the database and tables will be counted as an automatic migration, if you want a code-based migration for the initial create of the database and tables you must drop the database and begin using migrations against an empty or non-existent database.

Improved error logging when an exception is encountered.

The bugs that required SQL Compact and SQL Express to be available are now resolved.

Known Issues

Some known issues, and ‘yet to be implemented’ features include:

Code-based migrations and databases generated with Alpha 2 cannot be used with Alpha 3.Because Alpha 2 was such an early release we needed to make some changes to the table we use to store migrations and the way we generate and identify code-based migrations. If you were using Alpha 2 you will need to regenerate migrations and run them to create your database. We realize this is painful but it is one of the trade-offs associated with getting previews into your hands early in the development process. We are making an effort to reduce such changes in future previews.

If you are updating the EntityFramework.Migrations package you will need to close and re-open Visual Studio after updating. This is required to reload the updated command assemblies.

No outside-of-Visual-Studio experience. Alpha 2 only includes the Visual Studio integrated experience. We also plan to deliver a command line tool and an MSDeploy provider for Code First Migrations.

Feedback

We really want your feedback on Code First Migrations. Is the solution we are delivering what you want? Are there features we should add? Please comment on this post with any feedback you might have.

Getting Started

There are two walkthroughs for Alpha 3, one focuses on the no-magic workflow that uses a code-based migration for every change. The other looks at using automatic migrations to avoid having lots of code in you project for simple changes.

Prerequisites & Incompatibilities

Migrations is dependent on EF 4.1 Update 1, this updated release of EF 4.1 will be automatically installed when you install the EntityFramework.Migrations package.

Important: If you have previously run the EF 4.1 stand alone installer you will need to upgrade or remove the installation before using migrations. This is required because the installer adds the EF 4.1 assembly to the Global Assembly Cache (GAC) causing the original RTM version to be used at runtime rather than Update 1.

This release is incompatible with “Microsoft Data Services, Entity Framework, and SQL Server Tools for Data Framework June 2011 CTP”.

Support

This is a preview of features that will be available in future releases and is designed to allow you to provide feedback on the design of these features. It is not intended or licensed for use in production. If you need assistance we have an Entity Framework Pre-Release Forum.

@Andrew J Peters – So take this snippet from a migration code file, and assuming a "Customer" has many "Shipping Addresses", you would set this foreign key to cascade on delete to get rid of all the shipping addresses this customer owns?

For the most part, how you configure your Code First model _will_ determine what we do in Migrations. The way Code First works is that it builds an underlying model (EDM) by combining the info from your classes, data annotations and fluent API configuration. Migrations uses this model in order to work out what to do. For example, if you want to rename a column the steps would be:

1) Apply the Column data annotation to the property in your model

2) Run Add-Migration; we will scaffold a migration with a single RenameColumn call.

@Andrew – My model is agnostic of the ORM/Data Layer, it cares nothing about how it gets persisted. With that said, I don't want to pollute the model with EF specific attributes. That is why I thought the EntityConfiguration Fluent API was neat, it gave me a way to control the model in a EF specific way.

I can confirm that only parts of the Fluent API have an effect on migrations, such as "HasMaxLength" and "IsRequired/IsOptional". "HasMany.WithRequired" and vice versa do not have any effect on the migration in my experience.

I think I found the problem. There is a bug in our scaffold code generator where we are not correctly generating "cascadeDelete: false" for the CreateTable().ForeignKey() API. For now, you will need to manually edit the generated migration and add the missing cascadeDelete parameter.

@Ben, non-public properties work now, it's just that they aren't included in your model by default. To include them they need to be registered with the DbModelBuilder using the fluent API. Because they aren't public, it can be more difficult to refer to them from configuration code. One approach is to nest a derived EntityConfiguration class inside the Entity and configure that way. Another is to create static readonly Expression fields in the Entity that refer to the non-public properties – the static fields can then be used in place of the actual properties in fluent API calls.

I have been using alpha3 for a couple of months and a consistent problem occurs. I have multiple projects all accessing the same database. When I use Update-Database or Add-Migration on more than the same project in any one session of Visual Studio Web Developer 2010 Express I get the last project's migration added to the current project's migration as a drop in the Up method and as create in Down method. I have to remove the config string from the project, do an Add-Migration, edit the migration to remove the inappropriate source, add the connection string and then call Update-Database. I have not seen anyone else mention this. I think it started after updating NuGet to the newest version but am not certain.

I am using code first migrations alpha 3 with my mvc project. I must say that i was really looking forward to Migrations since I started using MVC and Codefirst last January. Well done guys!!

Migrations is working fine, when I run update-database the first time it is creating a new database called BillingEngine.Models.BillingEngineContext instead of BillingEngine as previously without migrations.

Any further updated are then performed on the BillingEngine.Models.BillingEngineContext database.

Please note that BillingEngine.Models is a namespace and BillingEngineContext is the class inheriting DBcontext, which is contained in the mentioned namespace.

Can I use the API to specify the name of the database somewhere?. I would work if update the connection stings to use the new name but its a bit messy and too long a name.

Great job so far, guys, but please change the way the migration scripts are generated.

The script generator doesn't specify a default PK constraint name in the generated CREATE TABLE statement. When you don't specify the primary key constraint name, SQL Server creates a cryptic one for you like:

PK__User__1788CCAC27F8EE98

In the table designer in SSMS, the convention for the default PK name is as follows:

PK_{table name}

Please make the script generator specify the primary key constraint name by default using the SSMS naming convention, and optionally add the ability to override this default constraint name by adding an overload to the TableBuilder.PrimaryKey() method that allows for passing a constraint name argument.

The script generator does happen to specify a foreign key constraint name in the generated script. However, the naming convention is as follows:

FK_{child table name}_{parent table name}_{column name}

The designers in SSMS create FK constraint names with this convention:

FK_{child table name}_{parent table nae

Please make the script generator follow the same convention as SSMS, and optionally add an overload to the TableBuilder.ForeignKey() method that allows specifying the constraint name as described above for the TableBuilder.PrimaryKey() method.