While trying to reproduce #863, I am getting the same error on the dotnet ef update database command, which uses the same migration classes under the hood. Checking this now.

This might happen, if you create a new ASP.NET Core project (with the authentication option enabled), change the EF Core provider to Pomelo.EntityFrameworkCore.MySql and then run a migration or update command.

The issue is that VS assumed that you are going to use SQL Server, so it tried to help you and already added the initial migration CreateIdentitySchema to the files .\Data\Migrations\00000000000000_CreateIdentitySchema.cs (containing the Up and Down operations) and .\Data\Migrations\00000000000000_CreateIdentitySchema.Designer.cs (containing the highly database dependent target model), that were generated using the SQL Server provider.

That is indeed a step less to take care of, if you are using SQL Server. It will contain a wrong migration however, if you are using any other database provider.

If you are using just MySQL and not also SQL Server, the easiest way to fix this is to first make sure, that UseMySql() is being called in your ConfigureServices method:

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

This might happen, if you create a new ASP.NET Core project (with the authentication option enabled), change the EF Core provider to Pomelo.EntityFrameworkCore.MySql and then run a migration or update command.

The issue is that VS assumed that you are going to use SQL Server, so it tried to help you and already added the initial migration CreateIdentitySchema to the files .\Data\Migrations\00000000000000_CreateIdentitySchema.cs (containing the Up and Down operations) and .\Data\Migrations\00000000000000_CreateIdentitySchema.Designer.cs (containing the highly database dependent target model), that were generated using the SQL Server provider.

in Pomelo.EntityFrameworkCore.MySql Version 2.2, it works without Deleting and recreate CreateIdentitySchema,

The create table script generated

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;

without any errors,

I hope 3.0 + should work the same for compatibility and availability.

is there any reason for this change?

thanks,

in Pomelo.EntityFrameworkCore.MySql Version 2.2, it works without Deleting and recreate CreateIdentitySchema

If it worked for you in Pomelo 2.2 without any change, than that is great, but cannot be generalized because it is highly dependent on your configuration (and key type).

As written above, you should regenerate the initial migration when creating a new project, to ensure that you get a valid migration and model definition. If you don't, you are on your own and might need to tinker with the generated code a bit to make it work (this can be done without too much effort depending on your MySQL knowledge).

There have been some breaking changes for the 3.0 release (that should be tagged appropriately), so as for any major or minor upgrade, test your code first in your development and staging environment before moving it to production.

without any errors,
[...]
is there any reason for this change?

What errors and change in 3.0 are you concretely talking about?

There have been a lot of changes from 2.2.6 to 3.0.0, so feel free to post us a problematic model class, its definition, the generated migration and the resulting SQL script, so we can talk about any issues you are having.