Badam użycie Migracji EF w oparciu o kod dla produktu, którynie użyj EF. Wszystko ogólnie działa dobrze, z wyjątkiem polecenia:

Add-Migration MyTestMigration

wyświetla następujący komunikat:

Nie można wygenerować migracji jawnej, ponieważ oczekują następujące migracje jawne: [201206260845338_DannyTest]. Zastosuj oczekujące migracje jawne przed próbą wygenerowania nowej migracji jawnej.

Powodem tego jest fakt, że ciąg połączenia nie jest znany w czasie kompilacji, a EF losowo utworzyło bazę danych o nazwie „MyContextName” w. SQLExpress. Nie mogę zastosować oczekującej migracji, ponieważ odwołuje się do tabel bazy danych, które nie istnieją w tej bazie danych - próbujemy po prostu użyć migracji jako sposobu wykonywania naszych skryptów;

Tak więc pytania są następujące:

Jeśli nie korzystamy z automatycznych migracji (mamy EnableAutomaticMigrations = false), dlaczegoAdd-Migration wymagać, aby baza danych była aktualnanawet jeśli nie ma to absolutnie żadnego wpływu na wygenerowaną (pustą) migrację? Trudno mi uwierzyć, że stwardnienie rozsiane nie zamierza tego przypadku, gdy tak dużo z niego działa; jedyną „zepsutą” rzeczą jest walidacja, która nie ma wpływukażdy zachowanie.

Czy jest jakiś sposób na to, oprócz tworzenia własnego polecenia Add-Migration, które po prostu powiela to, co robi EF, ale pomija (pozornie niepotrzebny) DB do sprawdzenia na bieżąco? Próbowałem przekazywać różne argumenty, ale jak dotąd nie udało się go uruchomić.

Edytować:

W rzeczywistości znalazłem lepszy sposób na rozwiązanie tego problemu, ale tak naprawdę nie jest to odpowiedź na te pytania, więc dodanie go tutaj. Mam nadzieję, że będzie czas na przekształcenie tego wpost na blogu!

Jedynym powodem, dla którego chciałem użyć Add-Migration, był cały guff, który pasował do DbMigration; ale zdałem sobie sprawę, że w klasie bazowej możemy zasadniczo wyeliminować potrzebę tego wszystkiego, ponieważ klasa bazowa automatycznie generuje identyfikator migracji z atrybutu. Cel jest identyczny dla wszystkich naszych migracji, ponieważ stan modelu się nie zmienia. Teraz po prostu ręcznie tworzymy nasze migracje w ten sposób (data jest wymagana do zbudowania identyfikatora, tak aby EF zastosował je w odpowiedniej kolejności):

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

TheMyDbMigration klasa ma właściwości Target / Source / Id. Obiekt docelowy jest zakodowany na stałe (ta sama wartość, co migracja dodana utworzona przy pierwszej migracji), źródło ma wartość null, a identyfikator jest pewną refleksją odczytującą atrybut MigrationAttribute. Oznacza to, że możemy teraz po prostu ręcznie utworzyć te klasy; co nie jest teraz dużym wysiłkiem, nie musimy się martwić o wszystkie elementy IMigrationMetadata :-)