En essayant de reproduire #863, j'obtiens la même erreur sur la commande dotnet ef update database , qui utilise les mêmes classes de migration sous le capot. Vérifier cela maintenant.

Cela peut se produire si vous créez un nouveau projet ASP.NET Core (avec l'option d'authentification activée), remplacez le fournisseur EF Core par Pomelo.EntityFrameworkCore.MySql , puis exécutez une commande de migration ou de mise à jour.

Le problème est que VS a supposé que vous alliez utiliser SQL Server, il a donc essayé de vous aider et a déjà ajouté la migration initiale CreateIdentitySchema aux fichiers .\Data\Migrations\00000000000000_CreateIdentitySchema.cs (contenant le Up et Down ) et .\Data\Migrations\00000000000000_CreateIdentitySchema.Designer.cs (contenant le modèle cible fortement dépendant de la base de données), qui ont été générés à l'aide du fournisseur SQL Server.

C'est en effet une étape de moins à prendre en charge, si vous utilisez SQL Server. Cependant, il contiendra une mauvaise migration si vous utilisez un autre fournisseur de base de données.

Si vous utilisez uniquement MySQL et pas également SQL Server, le moyen le plus simple de résoudre ce problème est d'abord de vous assurer que UseMySql() est appelé dans votre méthode ConfigureServices :

```c#
options.UtiliserMySql(
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:

les migrations dotnet ef ajoutent CreateIdentitySchema

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`)
);

Cela peut se produire si vous créez un nouveau projet ASP.NET Core (avec l'option d'authentification activée), remplacez le fournisseur EF Core par Pomelo.EntityFrameworkCore.MySql , puis exécutez une commande de migration ou de mise à jour.

Le problème est que VS a supposé que vous alliez utiliser SQL Server, il a donc essayé de vous aider et a déjà ajouté la migration initiale CreateIdentitySchema aux fichiers .\Data\Migrations\00000000000000_CreateIdentitySchema.cs (contenant le Up et Down ) et .\Data\Migrations\00000000000000_CreateIdentitySchema.Designer.cs (contenant le modèle cible fortement dépendant de la base de données), qui ont été générés à l'aide du fournisseur SQL Server.

dans Pomelo.EntityFrameworkCore.MySql Version 2.2, cela fonctionne sans Deleting et recréez CreateIdentitySchema,

Le script de création de table généré

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;

sans aucune erreur,

J'espère que 3.0 + devrait fonctionner de la même manière pour la compatibilité et la disponibilité.

y a-t-il une raison à ce changement ?

Merci,

dans Pomelo.EntityFrameworkCore.MySql Version 2.2, cela fonctionne sans supprimer et recréer CreateIdentitySchema

Si cela a fonctionné pour vous dans Pomelo 2.2 sans aucun changement, c'est bien, mais ne peut pas être généralisé car cela dépend fortement de votre configuration (et du type de clé).

Comme indiqué ci-dessus, vous devez régénérer la migration initiale lors de la création d'un nouveau projet, pour vous assurer d'obtenir une migration et une définition de modèle valides. Si vous ne le faites pas, vous êtes seul et devrez peut-être bricoler un peu le code généré pour le faire fonctionner (cela peut être fait sans trop d'effort en fonction de vos connaissances MySQL).

Il y a eu quelques changements de rupture pour la version 3.0 (qui doivent être étiquetés de manière appropriée), donc comme pour toute mise à niveau majeure ou mineure, testez d'abord votre code dans votre environnement de développement et de mise en scène avant de le déplacer vers la production.

sans aucune erreur,
[...]
y a-t-il une raison à ce changement ?

De quelles erreurs et changements dans la 3.0 parlez-vous concrètement ?

Il y a eu beaucoup de changements de 2.2.6 à 3.0.0, alors n'hésitez pas à nous poster une classe de modèle problématique, sa définition, la migration générée et le script SQL qui en résulte, afin que nous puissions parler de tous les problèmes que vous rencontrez.