How can I stop Add-Migration checking my database has no pending migrations when using Code-Based migrations?

.net c# ef-migrations entity-framework

Question

I'm looking at adopting Code-Based EF Migrations for a product that uses EF, which is has not. In general, everything goes well, except the command:

Add-Migration MyTestMigration

produces the following statement:

Unable to generate an explicit migration because the following explicit migrations are pending: [201206260845338_DannyTest]. Apply the pending explicit migrations before attempting to generate a new explicit migration.

Due to the connection string not being specified at build time, EF built a database on.SQLExpress named "MyContextName" at random. We're merely attempting to utilize migrations as a method of running our scripts, however I am unable to apply the pending migration since it references database tables that are not present in this database;

So, here are the inquiries:

  1. Why does this happen if we don't use Automatic Migrations (we have EnableAutomaticMigrations=false)?Add-Migration need the database to be current despite the fact that it has no effect whatsoever on the resulting (empty) migration? Since so much of it works and the only "broken" item is validation that has no effect on any behavior, it's difficult for me to think that MS didn't plan for this use case to exist.

  2. Is there any other solution to this than writing our own Add-Migration command that just does what the EF one does and omits the DB up-to-date check (which seems unnecessary)? I've tried passing other arguments, but I haven't been successful in doing so yet.

Edit:

Although it's not exactly a response to these questions, I actually discovered a better approach to handle this issue, so I'll provide it here. Hopefully I'll have enough time to make this a blog entry!

The DbMigration's associated guff was the sole reason I wanted to utilize Add-Migration, but I soon realized that with a base class, we could essentially do away with all of this by having the base class automatically construct the migration ID from a property. Since the model state is same throughout all of our migrations, the Target is the same. The migrations are currently created manually in the following manner (the date is necessary to generate the ID so that EF will apply them in the proper order):

[Migration(2012, 6, 27, 12, 00, "Add new xxx fields for yyy")]
internal class MyNewMigration : MyDbMigration
{
    public override Up()
    {
        // ...
    }
    public override Down()
    {
        // ...
    }
}

The MyDbMigration Target, Source, and Id are attributes of class. Source is null, Id is some reflection that reads the MigrationAttribute, and Target is hard-coded (the same value that Add-Migration produced with the initial migration). Now that we don't have to worry about the IMigrationMetadata thing, we can simply manually generate these classes, which isn't a lot of work.

1
7
6/27/2012 8:03:38 PM

Popular Answer

If your app won't launch, try commenting out any existing migrations (those that haven't been used to update the database established on.SQLExpress). That should add the first tables required to the local database.

You should be able to uncomment your migrations once the local database has the proper structure, and then use update-database to update the local database. Once that happens, you may add a new migration.

Also keep in mind that the update-database command's -connectionString argument allows you to focus your migrations on a particular server or database.

1
6/27/2012 6:17:42 AM


Related Questions





Related

Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow