[C# and EF] Tutorial: Entity Framework Code First Migrations 2/2

This second part of the series shows how to activate EF Code First Migrations and either handle them manually in code or – even more interesting - letting EF handle them automatically for you.

Manual Code-based EF Code First Migrations

The first possibility is to handle those changes manually from within your code. Here is how that works.

• Open the Package Manager Console from the Tools menu within Visual Studio 2012.

• Activate the manual EF Migration features by entering the command “Enable-Migrations”.

• This adds a new folder Migrations and also the auto-generated classes Configuration.cs  and [SOMEDATE]_InitialCreate.cs to your project.

• The Configuration.cs class allows you to configure the EF Code First Migrations options and seed data after migration (very useful for testing purposes during development).

• The other class contains all the code necessary to create the database (Up) and also drop it (Down) if necessary.

• Here is an example of what can be found in the Up() method.

• Here is an example of what can be found in the Down() method.

From here you may start to implement you own code in C# for handling EF Code First and database schema changes.

Automatic EF Code First Migrations

Being able to handle database schema changes related to EF Code First changes from C# code is great, you won’t need to be an expert of database development anymore. But you still need to know what to change and you still need to allocate some time for it.

What if there would be a fully automated way of handling those changes without any effort? Well there is and you just have to activate it. Here is how that works.

• Open the Package Manager Console from the Tools menu within Visual Studio 2012.

• Activate the automatic EF Migration features by entering the command “Enable-Migrations -EnableAutomaticMigrations”.
• If you try that on a project where you have already activated the manual EF Code First features, you just need to delete the Migrations folder first.

• If you look into the Configuration.cs file you will see that the flag to activate automatic migrations is now enabled.

• When you now change the EF Code First model as explained in the first post of the series, you may start the automatic migration of the database via the Package Manager console by entering “Update-Database”.

• And you see that the automatic migration was not applied because it would result in data loss. By default it is not allowed to apply automatic migrations if there is data loss implied. This is a security feature to not accidently delete important data from the database. Mind that you may revert back to an old database schema but you won’t get back deleted data!
• So now it is up to you to either review the changes or allow automatic migrations if there is data loss (really use this with percaution!!).
• To allow data loss you just set the flag AutomaticMigrationsDataLossAllowed to true in the Configuration constructor.

• When you restart the automatic migration of the database via the Package Manager console by entering “Update-Database” (you may want to add the “–Verbose” flag) you see all the changes that were applied.

• You can now use your application as expected. The modifications in the database reflect the EF Code First model changes.

[C# and EF] Tutorial: Entity Framework Code First Migrations 2/2

[C# and EF] Tutorial: Entity Framework Code First Migrations 1/2

I showed you how to use the Entity Framework Code First approach in one of my last blog posts. This approach is very useful if you want to begin with the implementation and there is no database yet. You want to concentrate on the code and not worry about the database at all, therefore letting Entity Framework auto-generate the database for you.

This is especially interesting for developers not having too much experience in database development or in cases where you have to deliver very quickly and you just don’t want to bother with database design.

The problem : Lack of handling Code First model changes in the DB

Code First works very well and is very easy to use. But it lacks an important feature as I have already pointed out in one of my other blog posts – the handling of database schema changes (add/delete/modify columns, add/delete/modify data types, add/delete/modify constraints, etc…) related to EF Code First model changes .

When you change the underlying EF Code First model expressed in your code (via POCO classes for example) and/or its restrictions you either have to re-create the whole database, meaning that all your data gets lost in the process (not acceptable in production use), or code the database changes manually via SQL upgrade scripts.

In this case the developer still needs to have good database development skills and spent time to create, test and execute the upgrade scripts. This is a tedious task, which the new version of Entity Framework 5.0 integrated in .NET 4.5  is going to greatly simplify and automate.

The solution: Code First Migrations

Microsoft heard the customer requests concerning this problem and added what is called Entity Framework Migrations. It is very easy to activate, and though not perfect, serves very well for applying necessary database schema changes if you work with EF Code First.

Let me show you how it works by providing an example in Visual Studio 2012.

• Create a new project (for the example a console project but you may as well use any other type of project).

• Now do a right click on the project in the Solution Explorer and select to manage the NuGet packages for it.

• In the Nuget packages window search for Entity Framework and select version 5.0 (currently as a release candidate, this won’t be necessary in the future since it will be fully integrated in .NET 4.5).

• This will allow you to use Code First and do an example implementation : a POCO class Person.
• When you run your application and use the DataContext, the database and all its columns and constraints get automatically generated. Everything works fine and your application works as expected.

• Now you get an application change request and you decide to change the EF Code First model by changing the POCO class.

• But if you try to change the underlying POCO classes of an already generated database and execute your application, you will get the following exception.

• This is the expected behavior since the new EF Code First Migrations features are not activated by default. You have to activate them manually and configure them according to your needs.
• To do this open the Package Manager Console from the Tools menu within Visual Studio 2012 and activate the EF Code First Migration features from there.

In the next part of the series I am going to explain how to activate either the manual or the automatic features of EF Code First Migrations so stay tuned.

[C# and EF] Tutorial: Entity Framework Code First Migrations 1/2