Förvandlar Mark G:s kommentar till ett svar.
När tabellen __EFMigrationsHistory har skapats bör resten av uppdateringen köras.
CREATE TABLE `__EFMigrationsHistory` ( `MigrationId` nvarchar(150) NOT NULL, `ProductVersion` nvarchar(32) NOT NULL, PRIMARY KEY (`MigrationId`) );
Alternativt, generera skriptet för dina migrering(ar) och ansök till databasen manuellt med det här kommandot i Package Manager Console:
Script-Migration
Om du behöver generera Alla skript kan du använda detta kommando:
Script-Migration -from 0
Stötte på samma problem när jag använde standard Oracle-leverantör.
Enligt denna fråga skapar Dot Net Entity Framework-databasuppdateringen inte tabeller i mysql-databasen, den har inte migreringsfunktionen implementerad ännu.
Jag följde förslagen när jag bytte till SapientGuardian-leverantör och det verkar vara den bästa vägen att gå nu.
Edit:som föreslagits i kommentarerna är Pomelo det bästa alternativet från början av 2018. Jag har valt det framför andra leverantörer sedan mitt ursprungliga svar.
Jag stöter på samma problem, OP-kontexten kan vara något annorlunda men här är mitt svar för fullständighetens skull.
Ett av sätten du kan stöta på det här problemet är om:
- Du skapar en migrering och uppdaterar databasen,
- Senare av någon anledning släpper du dina tabeller (inte databasen) och försöker köra kommandot update-databse igen.
I så fall får du felet rapporterat av OP
Lösningen i det här fallet är att släppa hela databasen . Därefter körs kommandot update-databse framgångsrikt.
Jag är inte säker på om det bara är relaterat till mysql, men för att återuppta :
- Om du släpper tabellerna men använd en befintlig databas (som hade tidigare migrering), kommer uppdateringskommandot att ge dig ett undantag.
- Om du släpper hela databasen , kommer uppdateringskommandot att köras perfekt.