Replace Pomelo.EntityFrameworkCore.MySql with Microting.EntityFrameworkCore.MySql for .NET 10+

[Copilot]

Pomelo.EntityFrameworkCore.MySql stopped updating after 9.x, leaving no support for .NET 10. This replaces it with Microting.EntityFrameworkCore.MySql (a drop-in fork) for net10.0 targets, while keeping Pomelo for net8.0/net9.0.

Package version changes (Directory.Packages.props)

• Added MicrotingVersion=10.0.9 to the net10.0 PropertyGroup; removed PomeloVersion from net10.0 (no longer used)
• Updated net10.0 EF Core provider versions to match EF Core 10 (required by Microting 10.0.9):
  • EntityFrameworkVersion: 9.0.0 → 10.0.10
  • NpgsqlEntityFrameworkCorePostgreSQLVersion: 9.0.0 → 10.0.3
  • GaussDBEntityFrameworkCoreVersion: 9.0.0 → 10.0.0
  • KingbaseESEntityFrameworkCoreVersion: 9.0.0 → 10.0.0
  • MongoDBEntityFrameworkCoreVersion: 9.0.3 → 10.0.2
• Added symmetric PackageVersion entries with non-empty conditions for both providers:

  <PackageVersion Include="Pomelo.EntityFrameworkCore.MySql" Version="$(PomeloVersion)" Condition="'$(PomeloVersion)' != ''" />
  <PackageVersion Include="Microting.EntityFrameworkCore.MySql" Version="$(MicrotingVersion)" Condition="'$(MicrotingVersion)' != ''" />

Project file changes (5 .csproj files)

Conditional package references added to each test project referencing Pomelo:

<PackageReference Include="Pomelo.EntityFrameworkCore.MySql" Condition="'$(TargetFramework)' != 'net10.0'" />
<PackageReference Include="Microting.EntityFrameworkCore.MySql" Condition="'$(TargetFramework)' == 'net10.0'" />

Namespace shim (ShardingMySqlMigrationsSqlGenerator.cs)

Microting uses its own namespace prefix (Microting.*) rather than Pomelo.*. Added #if NET10_0_OR_GREATER guards around the affected using directives:

#if NET10_0_OR_GREATER
using Microting.EntityFrameworkCore.MySql.Infrastructure.Internal;
using Microting.EntityFrameworkCore.MySql.Migrations;
#else
using Pomelo.EntityFrameworkCore.MySql.Infrastructure.Internal;
using Pomelo.EntityFrameworkCore.MySql.Migrations;
#endif

The type names (MySqlMigrationsSqlGenerator, IMySqlOptions) are identical across both packages, so no other code changes are required.

[witskeeper]

@copilot 修复action报错

[Copilot]

@copilot 修复action报错

The failure was caused by ShardingCore 7.9.1.24 only having a net8.0 TFM group with an EF Core 9 dependency — when resolved on net10.0 it falls back to that incompatible build, causing transaction lifecycle issues (Already committed or rolled back).

Fixed in commit Fix net10.0 CI: upgrade ShardingCore to 7.10.2.1 for EF Core 10 compatibility by bumping ShardingCoreVersion for net10.0 from 7.9.1.24 → 7.10.2.1. That release adds a proper net10.0 TFM group with EF Core 10 as its dependency. Build confirmed clean locally.

[witskeeper]

@copilot action仍然有错

[Copilot]

@copilot action仍然有错

Fixed in commit Fix: clear CurrentTransaction before CommitAsync to prevent rollback-after-commit on ShardingCore+Microting net10.0.

Root cause: ShardingRelationalTransaction.CommitAsync commits the primary MySQL shard first (base.RelationalTransaction.CommitAsync), then commits secondary shards and calls CAP's FlushAsync. If anything throws after the physical commit (e.g. a secondary-shard commit error or CAP flush failure), the catch block in CommandUnitOfWorkBehavior calls RollbackAsync on the already-committed primary transaction, causing MySqlConnector.MySqlTransaction.VerifyValid() to throw InvalidOperationException: Already committed or rolled back.

Fix: In CommitAsync on all three context base classes (AppDbContextBase, AppIdentityDbContextBase, AppIdentityUserContextBase), CurrentTransaction is now cleared before calling the transaction's own CommitAsync. If CommitAsync then throws for any reason, the catch block sees CurrentTransaction == null and skips the explicit rollback. The await using dispose path (already held by the calling code) safely handles cleanup — MySqlTransaction.DisposeAsync rolls back uncommitted transactions and is a no-op for committed ones, so data integrity is preserved in all cases.