Estou investigando usando Migrações EF baseadas em código para um produto quenão use EF. Tudo geralmente funciona bem, exceto que o comando:

Add-Migration MyTestMigration

Mostra a seguinte mensagem:

Não é possível gerar uma migração explícita porque as seguintes migrações explícitas estão pendentes: [201206260845338_DannyTest]. Aplique as migrações explícitas pendentes antes de tentar gerar uma nova migração explícita.

A razão para isso é que a cadeia de conexão não é conhecida no momento da criação, e a EF criou aleatoriamente um banco de dados chamado "MyContextName" em. \ SQLExpress. Não posso aplicar a migração pendente, porque ela faz referência a tabelas de banco de dados que não existem neste banco de dados - estamos apenas tentando usar as migrações como uma maneira de executar nossos scripts;

Então as perguntas são:

Se não estivermos usando migrações automáticas (temos EnableAutomaticMigrations = false), por queAdd-Migration exigir que o banco de dados esteja atualizadomesmo que não tenha absolutamente nenhum impacto na migração gerada (vazia)? Eu acho difícil acreditar que a MS não tenha a intenção deste caso de uso quando muito disso funciona; a única coisa "quebrada" é a validação que não afetaqualquer comportamento.

Existe alguma maneira de contornar isso além de criar nosso próprio comando Add-Migration que apenas duplica o que o EF faz, mas pula a verificação de DB (aparentemente desnecessária) atualizada? Eu tentei passar vários argumentos, mas até agora não consegui fazê-lo funcionar.

Editar:

Na verdade, encontrei uma maneira melhor de resolver esse problema, mas não é realmente uma resposta para essas perguntas, portanto, adicione-o aqui. Espero que tenha tempo para transformar isso em umpostagem no blog!

A única razão pela qual eu queria usar o Add-Migration era por causa de todo o guff que acompanhava o DbMigration; mas percebi que, com uma classe base, poderíamos basicamente eliminar a necessidade de tudo isso fazendo com que a classe base gerasse automaticamente o ID de migração de um atributo. O Target é idêntico para todas as nossas migrações, pois o estado do modelo não muda. Agora, nós apenas criamos manualmente nossas migrações como esta (a data é necessária para construir o ID de tal forma que a EF irá aplicá-las na ordem correta):

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

oMyDbMigration class tem as propriedades Target / Source / Id. O destino é codificado (o mesmo valor que Add-Migration criou com a primeira migração), Source é null e Id é algum reflexo que lê o atributo MigrationAttribute. Isso significa que agora podemos apenas criar manualmente essas classes; o que não é um grande esforço agora, não precisamos nos preocupar com todas as coisas do IMigrationMetadata :-)