Beim Versuch, #863 zu reproduzieren, erhalte ich den gleichen Fehler beim Befehl dotnet ef update database , der die gleichen Migrationsklassen unter der Haube verwendet. Prüfe das jetzt.

Dies kann passieren, wenn Sie ein neues ASP.NET Core-Projekt erstellen (mit aktivierter Authentifizierungsoption), den EF Core-Anbieter in Pomelo.EntityFrameworkCore.MySql ändern und dann einen Migrations- oder Updatebefehl ausführen.

Das Problem ist, dass VS davon ausgegangen ist, dass Sie SQL Server verwenden werden, also hat es versucht, Ihnen zu helfen und hat bereits die anfängliche Migration CreateIdentitySchema zu den Dateien .\Data\Migrations\00000000000000_CreateIdentitySchema.cs hinzugefügt (die die Up und Down Operationen) und .\Data\Migrations\00000000000000_CreateIdentitySchema.Designer.cs (die das stark datenbankabhängige Zielmodell enthalten), die mit dem SQL Server-Anbieter generiert wurden.

Das ist in der Tat ein Schritt weniger zu beachten, wenn Sie SQL Server verwenden. Es enthält jedoch eine falsche Migration, wenn Sie einen anderen Datenbankanbieter verwenden.

Wenn Sie nur MySQL und nicht auch SQL Server verwenden, können Sie dies am einfachsten beheben, indem Sie zunächst sicherstellen, dass UseMySql() in Ihrer ConfigureServices Methode aufgerufen wird:

```c#
options.UseMySql(
Configuration.GetConnectionString("DefaultConnection"));

Then delete the entire `Migrations` folder and just run something similar to the following command, to recreate the initial migration compatible with MySQL:

dotnet ef-Migrationen fügen CreateIdentitySchema hinzu

After that, the newly created initial migration will be compatible with MySQL and other operations based on that migration will be as well.

For example, the `CREATE TABLE` script for `AspNetRoles` when creating a migration script (by using `dotnet ef migrations script`) will look like this:

```sql
CREATE TABLE `AspNetRoles` (
    `Id` varchar(255) NOT NULL,
    `Name` varchar(256) NULL,
    `NormalizedName` varchar(256) NULL,
    `ConcurrencyStamp` longtext NULL,
    CONSTRAINT `PK_AspNetRoles` PRIMARY KEY (`Id`)
);

Dies kann passieren, wenn Sie ein neues ASP.NET Core-Projekt erstellen (mit aktivierter Authentifizierungsoption), den EF Core-Anbieter in Pomelo.EntityFrameworkCore.MySql ändern und dann einen Migrations- oder Updatebefehl ausführen.

Das Problem ist, dass VS davon ausgegangen ist, dass Sie SQL Server verwenden werden, also hat es versucht, Ihnen zu helfen und hat bereits die anfängliche Migration CreateIdentitySchema zu den Dateien .\Data\Migrations\00000000000000_CreateIdentitySchema.cs hinzugefügt (die die Up und Down Operationen) und .\Data\Migrations\00000000000000_CreateIdentitySchema.Designer.cs (die das stark datenbankabhängige Zielmodell enthalten), die mit dem SQL Server-Anbieter generiert wurden.

in Pomelo.EntityFrameworkCore.MySql Version 2.2 funktioniert es ohne Löschen und Erstellen von CreateIdentitySchema,

Das erzeugte Skript zur Tabellenerstellung

CREATE TABLE `aspnetroles` (
  `Id` varchar(255) NOT NULL,
  `Name` varchar(256) DEFAULT NULL,
  `NormalizedName` varchar(256) DEFAULT NULL,
  `ConcurrencyStamp` longtext,
  PRIMARY KEY (`Id`),
  UNIQUE KEY `RoleNameIndex` (`NormalizedName`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

ohne Fehler,

Ich hoffe, 3.0+ sollte aus Kompatibilitäts- und Verfügbarkeitsgründen genauso funktionieren.

gibt es einen grund für diese änderung?

Danke,

in Pomelo.EntityFrameworkCore.MySql Version 2.2 funktioniert es ohne Löschen und Erstellen von CreateIdentitySchema

Wenn es in Pomelo 2.2 ohne Änderungen für Sie funktioniert hat, ist das großartig, kann aber nicht verallgemeinert werden, da es stark von Ihrer Konfiguration (und Ihrem Tastentyp) abhängt.

Wie oben beschrieben, sollten Sie beim Erstellen eines neuen Projekts die anfängliche Migration neu generieren, um sicherzustellen, dass Sie eine gültige Migrations- und Modelldefinition erhalten. Wenn Sie dies nicht tun, sind Sie auf sich allein gestellt und müssen möglicherweise ein wenig am generierten Code herumbasteln, damit er funktioniert (dies ist je nach Ihren MySQL-Kenntnissen ohne großen Aufwand möglich).

Es gab einige grundlegende Änderungen für die Version 3.0 (die entsprechend gekennzeichnet werden sollten). Testen Sie Ihren Code daher bei jedem größeren oder kleineren Upgrade zuerst in Ihrer Entwicklungs- und Stagingumgebung, bevor Sie ihn in die Produktion überführen.

ohne Fehler,
[…]
gibt es einen grund für diese änderung?

Von welchen Fehlern und Änderungen in 3.0 sprichst du konkret?

Es gab viele Änderungen von 2.2.6 auf 3.0.0, also zögern Sie nicht, uns eine problematische Modellklasse, ihre Definition, die generierte Migration und das resultierende SQL-Skript zu posten, damit wir über alle Probleme sprechen können, die Sie haben.