EF Code First Migrations - how does it remember the previous model change? - entity-framework-4.3

Question

So i'm using Entity Framework Code First Migrations.
I make a change to my model, add a new manual migration and it gets the up script wrong.
So I delete the migration, and at the same time that I am not going to change it the way I thought. Upon deletion of the migration class and a reset of the model (ie setting it back as it was) I then change my model again.
When I generate a new migration, this migration acts as If it is changing from the one that I deleted.
how does entity framework code first know the last model state if you clean and delete a migration?
And how do you reset this?

Answer 1

In your database, under "Tables / System Tables" (assuming you use SQL Management Studio), edit the Table __MigrationHistory.
Got me stumbled too, after I had deleted all migrations *.cs files and still VS "knew" about old migrations!!

Answer 2

You probably didn't delete the Designer file underneath it that contains information about automatic migrations up until that point.
http://msdn.microsoft.com/en-US/data/jj554735
Run the Add-Migration AddBlogRating command...
The migration also has a code-behind file that captures some metadata. This metadata will allow Code First Migrations to replicate the automatic migrations we performed before this code-based migration. This is important if another developer wants to run our migrations or when it’s time to deploy our application.
The code-behind is a file like 201206292305502_AddBlogRating.Designer.cs, underneath the manual migration class you created. It looks like:
public sealed partial class AddBlogRating : IMigrationMetadata
{
string IMigrationMetadata.Id
{
get { return "201206292305502_AddBlogRating"; }
}
string IMigrationMetadata.Source
{
get { return "H4sIAAAAAAAEAOy9B2AcSZ...=="; }
}
string IMigrationMetadata.Target
{
get { return "H4sIAAAAAAAEAOy9B2AcSZ...=="; }
}
}
​
Those 2 strings are base64 encoded dumps of your entire model prior to the migration and after it. The idea being that anything prior to the first manual migration logged was automatic, so when you apply all this to a fresh DB it can look and say:
Manual1
Manual2
Check Source to determine goal model before Manual1, apply using the Automatic approach, apply Manual1, check Source on Manual2, use automatic approach to get there, apply Manual2, finally use automatic approach to get from there to the current compiled model state.