Ich untersuche die Verwendung von Code-Based EF Migrations für ein Produkt, dasnicht benutze EF. Alles funktioniert im Allgemeinen gut, außer dass der Befehl:

Add-Migration MyTestMigration

gibt die folgende Meldung aus:

Es kann keine explizite Migration generiert werden, da die folgenden expliziten Migrationen ausstehen: [201206260845338_DannyTest]. Wenden Sie die ausstehenden expliziten Migrationen an, bevor Sie versuchen, eine neue explizite Migration zu generieren.

Der Grund dafür ist, dass die Verbindungszeichenfolge zum Zeitpunkt der Erstellung nicht bekannt ist und EF zufällig eine Datenbank mit dem Namen "MyContextName" unter. \ SQLExpress erstellt hat. Ich kann die ausstehende Migration nicht anwenden, da sie auf Datenbanktabellen verweist, die in dieser Datenbank nicht vorhanden sind. Wir versuchen lediglich, Migrationen zum Ausführen unserer Skripts zu verwenden.

Die Fragen sind also:

Wenn wir keine automatischen Migrationen verwenden (wir haben EnableAutomaticMigrations = false), warum?Add-Migration erfordern, dass die Datenbank auf dem neuesten Stand istobwohl es absolut keinen Einfluss auf die generierte (leere) Migration hat? Es fällt mir schwer zu glauben, dass MS diesen Anwendungsfall nicht beabsichtigt, wenn so viel davon funktioniert. Das einzige, was "kaputt" ist, ist die Validierung, die nichts bewirktirgendein Verhalten.

Gibt es irgendeinen anderen Weg, als unseren eigenen Add-Migration-Befehl zu erstellen, der nur das dupliziert, was der EF macht, aber die (scheinbar unnötige) DB-Aktualitätsprüfung überspringt? Ich habe versucht, verschiedene Argumente zu übergeben, aber bisher nicht geschafft, es zum Laufen zu bringen.

Bearbeiten:

Ich habe tatsächlich einen besseren Weg gefunden, um dieses Problem zu lösen, aber es ist nicht wirklich eine Antwort auf diese Fragen, also füge es hier hinzu. Hoffentlich wird es Zeit, dies in eine zu verwandelnBlogeintrag!

Der einzige Grund, warum ich Add-Migration verwenden wollte, war, dass mit der DbMigration so viel Aufhebens gemacht wurde. Ich erkannte jedoch, dass wir mit einer Basisklasse die Notwendigkeit für all dies im Grunde eliminieren konnten, indem die Basisklasse die Migrations-ID aus einem Attribut automatisch generierte. Das Ziel ist für alle Migrationen identisch, da sich der Modellstatus nicht ändert. Jetzt erstellen wir unsere Migrationen einfach manuell wie folgt (das Datum ist erforderlich, um die ID so zu erstellen, dass EF sie in der richtigen Reihenfolge anwendet):

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

DasMyDbMigration Klasse verfügt über die Eigenschaften Target / Source / Id. Target ist fest codiert (der gleiche Wert, den Add-Migration bei der ersten Migration erstellt hat), Source ist null und Id ist eine Reflexion, die das MigrationAttribute liest. Dies bedeutet, dass wir diese Klassen jetzt nur noch manuell erstellen können. Das ist nicht viel Aufwand, jetzt müssen wir uns nicht mehr um all das IMigrationMetadata-Zeug kümmern :-)