Я изучаю использование EF Migrations на основе кода для продукта, которыйdoes not используйте EF. Все в целом работает хорошо, за исключением того, что команда:

Add-Migration MyTestMigration

выводит следующее сообщение:

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.

Причина этого заключается в том, что строка соединения неизвестна во время сборки, и EF случайно создала базу данных с именем «MyContextName». на. \ SQLExpress. Я не могу применить отложенную миграцию, потому что она ссылается на таблицы базы данных, которых нет в этой базе данных - мы просто пытаемся использовать миграции в качестве способа выполнения наших сценариев;

Итак, вопросы:

If we're not using Automatic Migrations (we have EnableAutomaticMigrations=false), why does Add-Migration require that the database is up-to-date even though it has absolutely no impact on the generated (empty) migration? I find it hard to believe MS don't intend this use case when so much of it works; the only "broken" thing is validation that doesn't affect any behaviour.

Is there any way around this other than creating our own Add-Migration command that just duplicates what the EF one does, but skips the (seemingly needless) DB up-to-date check? I've tried passing various arguments, but so far not managed to make it work.

Edit:

Я действительно нашел лучший способ решить эту проблему, но на самом деле это не ответ на эти вопросы, поэтому добавьте его здесь. Надеюсь, будет время, чтобы превратить это вСообщение блога!

Единственная причина, по которой я хотел использовать Add-Migration, была из-за всей этой болтовни, которая шла вместе с DbMigration; но я понял, что с базовым классом мы могли бы по существу исключить необходимость всего этого, если бы базовый класс автоматически генерировал идентификатор миграции из атрибута. Цель является идентичной для всех наших миграций, поскольку модельное состояние не изменяется. Теперь мы просто вручную создаем наши миграции следующим образом (для создания идентификатора требуется дата, чтобы EF применила их в правильном порядке):

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

MyDbMigration класс имеет свойства Target / Source / Id. Target жестко запрограммирован (то же самое значение, что Add-Migration, созданный при первой миграции), Source равен null, а Id является некоторым отражением, которое читает MigrationAttribute. Это означает, что теперь мы можем просто вручную создать эти классы; что теперь не требует больших усилий, нам не нужно беспокоиться обо всем, что связано с IMigrationMetadata :-)