IT:AD:EF/CodeFirst/Migrations:HowTo:Get an Overview

When Enable-Migrations is applied to a project, a Migrations folder is created in the root of the project, that contains:

• The “Migrations/Configurations.cs” file that defines how Migrations are applied (Automatically, or not)
• Individual Migrations you will create, using IT:AD:EF/CodeFirst/Migrations:HowTo:Add-Migration

• Not really safe enough to use in anything but a POC – prefer using Coded Migrations/.
  • See: http://msdn.microsoft.com/en-US/data/jj554735
• Automatic Migrations are generated/transparently applied when Update-Database is invoked (and Automatic Migrations are enabled).
  • The process doesn't leave any Migrations in the Migrations folder (it's all pretty transparent).

Coded Migrations are the hand-crafted Migrations that you add to your project by using IT:AD:EF/CodeFirst/Migrations:HowTo:Add-Migration. The IT:AD:Powershell command creates one for you by analysing the current state of affairs – but it's super important that you look at the code it generated, to ensure the Migration is not a lossy one (dropping a column to make another, etc.).

Until IT:AD:Code First:Migrations became generally available, we used DbContext Initializers that dropped and recreated and reseeded databases. It was scary.

Important: This is no longer best practice.

We now use: MigrateDatabaseToLatestVersion<AppDbContext,Migrations.Configuration> to implement pending migrations when the application is started.

When MigrateDatabaseToLatestVersion is used, Seeding of Reference data, etc. gets moved from the old-style DbInitializers (the ones that dropped/recreated the Db) to the Migrations Configuration.cs file (it has a Seed method).

One does not move it to the individual Migrations (that's would bit of a pain…) as I'd like to believe that all seeding requirements are figured out early, before Migration is put into place – but I know that this will never be complete right from the start. This means that Seeding will be sporadically spread through individual Migrations.

But note that in the Configuration.cs Seed method one it will be invoked each time there is a migration – ie several times. Therefore, one has to use context.People.AddOrUpdate(c) rather than simply context.People.Add(c)…this has implications…

The powershell commands are located in the tools\EntityFramework.psm1 file of the Entity Framework installation.

The powershell code is mostly a wrapper around the System.Data.Entity.Migrations.MigrationsCommands found in the tools\EntityFramework\EntityFramework.PowerShell.dll file.

First a MigrationsCommands object is instantiated with all configuration parameters.

Then there is a public method on the MigrationsCommands object for each of the available commands.

Change tracking is done by serializing the model to the db in a hidden System Table called MigrationTable. If you try to script a db, it won't be exported with your other data (because it's a SystemTable). This can be a blessing and a nuisance. You may need to read: Contents of __MigrationsHistory Db Table