Wenn Entity Framework Core Migrations die Kontextklasse nicht finden können

Der Dotnet-Doktor  –  0 Kommentare

Eine Abweichung der Versionsnummer an der dritten Stelle kann dazu führen, dass die Schema-Migrationen nicht mehr funktionieren.

Gestern hatten wir in einem Entwicklungsprojekt für einen Kunden beim Anlegen einer Datenbankschemamigration mit dem PowerShell-Befehl Add-Migration in Entity Framework Core plötzlich die Fehlermeldung "No DbContext was found in assembly. Ensure that you're using the correct assembly and that the type is neither abstract nor generic.". Normalerweise sieht man diese Fehlermeldung, wenn man als "Default Project" in der Package Manager Console (PMC) das falsche Projekt ausgewählt hat (also ein Projekt, in dem es keinen "Entity Framework Core"-Kontext gibt) beziehungsweise das Projekt bei Add-Migration nicht das richtige Projekt im Parameter -Project angegeben hat.

In diesem Fall war aber das "Default Project" richtig eingestellt. Allerdings gab es eine andere Inkonsistenz, die mir auffiel: Der Entwickler hatte in dem Kontextklassenprojekt die "Entity Framework Core"-Pakete von Version 2.0.0 auf die Version 2.0.1 aktualisiert. In dem Projekt, in dem die "Entity Framework Core"-Werkzeuge (Microsoft.EntityFrameworkCore.Tools) installiert waren, waren diese aber noch in Version 2.0.0 vorhanden. Nach dem Update des Werkzeugpakets auf Version 2.0.1 fand Add-Migration die Kontextklasse wieder.

Fazit: Wieder einmal ein Beweis, dass Änderungen der Versionsnummer an der dritten Stelle nicht nur "kompatible Bugfixes" sind.

Das gilt übrigens nicht nur für Entity Framework Core. Mit anderen Produkten gab es diesen Fall in letzter Zeit auch häufiger, zum Beispiel bei Angular gab es diesen Fall auch schon, als man in Version 4.2.3 die in Version 4.2.0 eingebauten Validatoren für min und max wieder ausgebaut hat.