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



<callout type="Navigation" class="small">

* [[../|(UP)]]
{{indexmenu>.#2|nsort tsort}}


</callout>


<panel title="Summary">



</panel>


## Notes ##

#### The Project's Migrations Folder

When [[IT/AD/Code First/Migrations/HowTo/Enable-Migrations|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/Code First/Migrations/HowTo/Add-Migration]]


#### Automatic Migrations


* 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 [[IT/AD/Code First/Migrations/HowTo/Update-Database|Update-Database]] is invoked (and [[IT/AD/Code First/Migrations/HowTo/Enable or Disable Automatic Migrations|Automatic Migrations are enabled]]).
    * The process doesn't leave any Migrations in the Migrations folder (it's all pretty transparent).



#### Coded Migrations

Coded Migrations are the hand-crafted Migrations that you add to your project by using [[IT/AD/Code First/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.).


#### DbInitializers

Until [[IT/AD/Code First/Migrations/]] became generally available, we used DbContext `Initializer`s 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.



#### Seeding within Migrations

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...




#### Powershell commands

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.




#### __MigrationHistory

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: [[IT/AD/Code First/Migrations/HowTo/Script/Contents of __MigrationsHistory Db Table]]