升级 .NET 10 不想等 Pomelo?试试 Microting.EntityFrameworkCore.MySql

简介: 本文详解如何在Pomelo尚未支持EF Core 10时,平滑升级至.NET 10:介绍Microting——Pomelo的官方分支,专注快速适配新.NET版本,API高度兼容,仅需替换命名空间与NuGet包即可完成迁移。

本文将带你了解:想尽快升级 .NET 10 但 Pomelo 还没支持 EF Core 10 怎么办?Microting 是什么?如何平滑完成迁移?


一、背景:想升级 .NET 10,Pomelo 还没跟上怎么办?

1.1 .NET 10 LTS 已经到来

2025 年 11 月 11 日,微软在 .NET Conf 2025 大会上正式发布了 .NET 10。作为 LTS(长期支持)版本,.NET 10 将获得长达 3 年的官方支持,直至 2028 年 11 月。

对于希望尽早体验新特性、保持技术栈先进性的团队来说,升级到 .NET 10 有很多吸引力:

  • 安全更新保障:3 年内持续接收安全补丁
  • 性能提升:JIT 优化、硬件加速(AVX10.2、Arm64 SVE)、NativeAOT 改进等
  • 新特性可用:C# 14、EF Core 10、ASP.NET Core 增强、AI 能力集成等
  • 长期支持:LTS 版本提供更稳定的维护周期

1.2 MySQL EF Core 提供程序的版本节奏差异

对于使用 MySQL / MariaDB 作为数据库的 .NET 项目,Pomelo.EntityFrameworkCore.MySql 是最常用的 EF Core 提供程序。

Pomelo 是 .NET 生态中最主流的 EF Core MySQL 提供程序,微软官方文档也将其列为 MySQL / MariaDB 的推荐提供程序之一。截至 2026 年中,Pomelo 的 NuGet 总下载量已超过 1.26 亿次,日均下载约 7.6 万次,被近千个 NuGet 包和上百个 GitHub 开源项目依赖。

不过,Pomelo 的版本发布节奏与 .NET / EF Core 的官方发布节奏存在时间差。作为社区驱动的开源项目,Pomelo 由志愿者维护,版本更新需要一定时间。

以下是当前的版本支持现状:

组件 最新稳定版 目标框架 EF Core 版本 .NET 10 支持
Pomelo.EntityFrameworkCore.MySql 9.0.0 .NET 8.0 9.0.x 尚未推出
Microsoft.EntityFrameworkCore 10.0.x .NET 10.0 10.0.x ✅ 官方支持

简单来说:EF Core 10 已经发布半年多了,Pomelo 支持 EF Core 10 的稳定版本仍在开发中。

对于希望尽快升级到 .NET 10 的团队来说,如果不想等待 Pomelo 的官方更新,有没有其他选择呢?答案是有的——Microting.EntityFrameworkCore.MySql


二、为什么是 Microting?

2.1 Microting 是什么?

Microting.EntityFrameworkCore.MySql 是 Pomelo.EntityFrameworkCore.MySql 的一个官方分支(fork),由丹麦公司 Microting A/S 维护。

在 NuGet 包的描述中,它明确说明了自己的定位:

"This is a fast moving version of Pomelo.EntityFrameworkCore.MySql intended to follow .net release cycle closely! There are no intentions for this package to implement new features."

(这是 Pomelo.EntityFrameworkCore.MySql 的快速迭代版本,旨在紧密跟随 .NET 发布周期!本包无意实现新功能。)

换句话说,Microting 的定位非常清晰:

  • 紧跟 .NET 发布节奏:.NET 一出新版本,Microting 很快就会跟上
  • 功能与 Pomelo 对齐:不添加新功能,保持与 Pomelo 的功能一致性
  • API 高度兼容:作为直接分支,核心 API 基本不变
  • 不做功能创新:新功能需求应提交给上游 Pomelo 项目

2.2 谁在维护 Microting?

Microting 背后是一家丹麦的技术公司 Microting A/S,其核心产品是 Microting eForm——一个用于数字化纸质表单、检查表、工单等的移动和 Web 应用。

那么,一家做电子表单的公司为什么要维护一个 EF Core MySQL 提供程序?

答案很简单:Microting 自己的产品深度依赖 EF Core + MySQL,他们需要紧跟 .NET 的发布节奏,而 Pomelo 的更新速度满足不了他们的需求。于是,他们 fork 了 Pomelo,创建了自己的快速跟进版本,并开源回馈给社区。

这种"自己用,也让大家用"的模式,反而让 Microting 拥有了稳定的维护动力——只要 Microting 公司还在使用 .NET + MySQL,这个包就会持续更新。

2.3 版本跟进速度对比

用数据说话,看看 Microting 的跟进速度:

.NET / EF Core 版本 微软发布时间 Microting 首个稳定版 时间差
.NET 9 / EF Core 9 2024 年 11 月 2025 年 8 月 约 9 个月
.NET 10 / EF Core 10 2025 年 11 月 2025 年底 ~ 2026 年初 约 1 ~ 2 个月

注:.NET 9 时代 Microting 也有滞后,但从 .NET 10 开始跟进速度明显加快,已有多个 10.0.x 稳定版本发布。

而 Pomelo 呢?截至 2026 年 6 月,距离 .NET 10 发布已超过半年,Pomelo 的 EF Core 10 支持仍在开发中(GitHub 上有相关 Issue 跟踪,但尚无稳定版发布)。

2.4 谁在用 Microting?

虽然 Microting 的总下载量(约 28.6 万)远不及 Pomelo(1.26 亿),但已经有不少知名开源项目率先采用:

  • Squidex(⭐ 2.5K+)- Headless CMS 平台
  • Smartstore(⭐ 1.5K+)- 开源电商平台(已升级到 ASP.NET Core 10)
  • IoTSharp(⭐ 1.3K+)- IoT 平台
  • Virto Commerce(⭐ 1.3K+)- B2B 电商平台
  • abp-next-admin(⭐ 1.0K+)- ABP vNext 前端管理项目

这些项目的采用,从侧面验证了 Microting 的可用性和稳定性。


三、Pomelo vs Microting:全面对比

在决定迁移之前,我们需要清楚地了解两者的异同。

3.1 功能与 API 兼容性

好消息是:Microting 是 Pomelo 的直接分支,核心功能和 API 高度兼容。 迁移的主要工作量是命名空间替换,而非代码重写。

对比项 Pomelo Microting
根命名空间 Pomelo.EntityFrameworkCore.MySql Microting.EntityFrameworkCore.MySql
扩展方法名 UseMySql() UseMySql()(完全相同)
核心类型 MySqlServerVersionMySqlDbType 同名同功能
迁移生成器 MySqlMigrationsSqlGenerator 同名同功能
JSON 支持 ✅ 两种 Json 库均支持 ✅ 对应扩展包
空间数据 ✅ NetTopologySuite ✅ 对应扩展包
底层驱动 MySqlConnector MySqlConnector(版本更高)
新功能添加 社区驱动,逐步添加 明确声明不添加新功能

一句话总结:改个命名空间,其他基本不用动。

3.2 版本支持矩阵

对比项 Pomelo 9.0.0 Microting 10.0.9
最低 .NET 版本 .NET 8.0 .NET 10.0
EF Core 版本范围 >= 9.0.0 && <= 9.0.999 >= 10.0.8 && <= 10.0.999
MySqlConnector 版本 >= 2.4.0 >= 2.6.0
MySQL 8.x 支持
MariaDB 支持
Amazon Aurora
Azure Database for MySQL
.NET 10 原生支持

3.3 生态与社区对比

对比项 Pomelo Microting
NuGet 总下载量 ~ 1.262 亿 ~ 28.6 万
日均下载量 ~ 7.6 万 ~ 888
依赖的 NuGet 包数 ~ 944 个 ~ 25 个
依赖的 GitHub 仓库 ~ 133 个 ~ 11 个
维护主体 Pomelo Foundation(社区) Microting A/S(商业公司)
开源协议 MIT MIT
问题响应模式 社区驱动 商业驱动

从生态规模来看,Pomelo 仍然占据绝对优势。但 Microting 的优势在于版本跟进速度——这正是当前升级 .NET 10 最需要的。

3.4 维护模式的差异

这是两者最本质的区别:

  • Pomelo:社区驱动的开源项目,由志愿者维护,发布节奏取决于贡献者的时间和精力
  • Microting:商业公司维护的开源项目,维护动力来自公司自身产品的需求,发布节奏与 .NET 官方对齐

两种模式各有优劣:社区驱动的项目生态更繁荣,但发布节奏可能不稳定;商业驱动的项目发布更有保障,但一旦公司战略调整,项目可能停止维护。

不过好消息是,由于两者 API 高度兼容,未来如果 Pomelo 恢复快速更新,迁回去的成本也很低。


四、迁移实操指南

说了这么多,现在来看看具体怎么迁移。由于 Microting 与 Pomelo API 高度兼容,整个迁移过程相对简单。

4.1 迁移前准备

在开始迁移之前,请确保:

  1. 项目已备份:代码已提交到版本控制,数据库有备份
  2. 明确目标版本:确定要升级到的 .NET 版本和 Microting 版本
  3. 检查第三方依赖:确认项目中其他依赖 Pomelo 的第三方库是否有 Microting 兼容版本
  4. 在独立分支上操作:创建专门的迁移分支,不影响主开发线

4.2 步骤一:替换 NuGet 包引用

首先,卸载所有 Pomelo 相关的 NuGet 包:

# 卸载主包
dotnet remove package Pomelo.EntityFrameworkCore.MySql

# 卸载扩展包(如果使用了的话)
dotnet remove package Pomelo.EntityFrameworkCore.MySql.Json.Microsoft
dotnet remove package Pomelo.EntityFrameworkCore.MySql.Json.Newtonsoft
dotnet remove package Pomelo.EntityFrameworkCore.MySql.NetTopologySuite
dotnet remove package Pomelo.EntityFrameworkCore.MySql.Design

然后,安装对应的 Microting 包:

# 安装主包
dotnet add package Microting.EntityFrameworkCore.MySql --version 10.0.9

# 按需安装扩展包(版本号与主包保持一致)
dotnet add package Microting.EntityFrameworkCore.MySql.Json.Microsoft --version 10.0.9
dotnet add package Microting.EntityFrameworkCore.MySql.Json.Newtonsoft --version 10.0.9
dotnet add package Microting.EntityFrameworkCore.MySql.NetTopologySuite --version 10.0.9

💡 提示:Microting 的扩展包命名规则与 Pomelo 完全一致,只是将 Pomelo 替换为 Microting

4.3 步骤二:更新命名空间引用

在所有 C# 源文件中,将 Pomelo 命名空间替换为 Microting

全局替换前:

using Pomelo.EntityFrameworkCore.MySql;
using Pomelo.EntityFrameworkCore.MySql.Infrastructure;
using Pomelo.EntityFrameworkCore.MySql.Storage;
using Pomelo.EntityFrameworkCore.MySql.Json.Microsoft;
// ... 其他 Pomelo 命名空间

全局替换后:

using Microting.EntityFrameworkCore.MySql;
using Microting.EntityFrameworkCore.MySql.Infrastructure;
using Microting.EntityFrameworkCore.MySql.Storage;
using Microting.EntityFrameworkCore.MySql.Json.Microsoft;
// ... 其他 Microting 命名空间

你可以使用 IDE 的全局替换功能(如 Visual Studio 的 Ctrl+Shift+H、VS Code 的 Ctrl+Shift+H),将 using Pomelo. 批量替换为 using Microting.

⚠️ 注意:替换时请确认只替换 using 语句和类型引用中的 Pomelo,不要误替换注释、字符串等无关内容。

4.4 步骤三:验证 DbContext 配置

好消息是,DbContext 的配置代码基本不需要修改UseMySql() 扩展方法的签名和用法完全一致。

// Program.cs 或 Startup.cs
services.AddDbContext<YourDbContext>(
    dbContextOptions => dbContextOptions
        .UseMySql(
            connectionString,
            serverVersion => serverVersion.ServerVersion(new MySqlServerVersion(new Version(8, 0, 30)))
        )
        .LogTo(Console.WriteLine, LogLevel.Information)
        .EnableSensitiveDataLogging()
        .EnableDetailedErrors()
);

MySqlServerVersionMariaDbServerVersion 等类型的用法也完全相同。你只需要确保命名空间已经更新即可。

4.5 步骤四:处理迁移文件与快照

如果你的项目使用了 EF Core Migrations,需要检查迁移文件和快照文件。

4.5.1 检查迁移文件

打开 Migrations 目录下的迁移文件(*.cs),检查是否有硬编码的 Pomelo 命名空间引用:

  • 迁移文件顶部的 using 语句 → 需要替换
  • 迁移类中的属性、特性 → 通常不需要修改

4.5.2 检查模型快照

模型快照文件(*ModelSnapshot.cs)中可能包含提供程序特定的注解。检查其中是否有 Pomelo 相关的字符串引用。

4.5.3 生成新的迁移快照

建议在完成代码修改后,生成一个新的迁移来更新快照:

dotnet ef migrations add MigrateToMicroting

通常情况下,这个迁移不会产生实际的数据库变更(因为 Microting 与 Pomelo 的数据库行为一致),但会更新模型快照中的提供程序信息,确保后续迁移正常工作。

执行迁移:

dotnet ef database update

💡 提示:如果生成的迁移是空的(UpDown 方法中没有操作),那是正常的——说明数据库结构不需要变化。

4.6 步骤五:全面测试验证

迁移完成后,务必进行全面的测试:

测试类别 检查内容
基础功能 增删改查是否正常工作
LINQ 查询 各种查询是否能正确翻译和执行
迁移 迁移能否正常应用和回滚
高级功能 JSON 列、空间数据、事务等是否正常
性能 关键查询的性能是否有明显变化
集成测试 端到端业务流程是否正常

特别注意以下容易出问题的地方:

  • 连接字符串:Microting 同样基于 MySqlConnector,连接字符串格式兼容,但建议确认高级选项(如 AllowUserVariablesUseAffectedRows 等)是否正常工作
  • EF Core Tools:确保 dotnet ef 命令行工具版本与 EF Core 10 匹配
  • 第三方库:检查依赖 Pomelo 的第三方库(如 EFCore.BulkExtensions.MySql)是否兼容 Microting

五、注意事项与风险提示

虽然迁移过程相对简单,但仍有一些需要注意的地方。

5.1 第三方库兼容性风险

这是迁移过程中最可能遇到的问题

许多 EF Core 扩展库(如批量操作、审计日志、软删除等)可能直接依赖 Pomelo。如果这些库硬编码了对 Pomelo.EntityFrameworkCore.MySql 的引用,那么它们将无法与 Microting 一起使用。

应对策略:

  1. 检查项目中每个依赖 Pomelo 的第三方库
  2. 查看该库是否有支持 Microting 的版本或替代方案
  3. 如果没有,考虑是否可以移除该依赖,或自行 fork 适配

5.2 连接字符串与底层驱动

Microting 10.x 要求 MySqlConnector >= 2.6.0,而 Pomelo 9.0 要求的是 MySqlConnector >= 2.4.0。

虽然 MySqlConnector 是向后兼容的,但版本升级可能带来一些细微的行为变化。建议:

  • 查阅 MySqlConnector 的版本发布说明,了解 2.4 到 2.6 之间的变化
  • 特别关注连接字符串参数的默认值变化
  • 测试与连接管理相关的功能(连接池、超时、SSL 等)

5.3 回滚方案

迁移不是单向的。如果在测试中发现严重问题,你需要有回滚的能力:

  1. 代码回滚:由于迁移操作主要是命名空间替换和包引用更改,回滚同样简单——反向操作即可
  2. 数据库回滚:确保迁移前有数据库备份,避免迁移导致的数据问题
  3. 版本分支:在独立的 Git 分支上进行迁移,方便随时切换回 Pomelo 版本

5.4 长期维护考量

选择 Microting 意味着选择了一种不同的维护模式。以下是一些需要考虑的长期因素:

Microting 的优势:

  • 发布节奏快,紧跟 .NET 版本
  • 商业公司维护,有稳定的维护动力
  • MIT 协议,与 Pomelo 相同

Microting 的潜在风险:

  • 生态规模较小,遇到问题时可参考的资料较少
  • 维护主体是单一公司,如果公司战略调整,项目可能停止维护
  • 不添加新功能,如果需要新的 MySQL / EF Core 特性,仍需等待 Pomelo 实现后 Microting 跟进

建议:将 Microting 视为一个过渡方案并行选项。如果未来 Pomelo 恢复了快速的版本更新,你可以根据实际情况选择继续使用 Microting 或迁回 Pomelo——由于 API 高度兼容,迁移成本很低。

5.5 生产环境部署建议

对于生产环境的升级,建议采取谨慎策略:

  1. 先在测试环境充分验证:至少运行 1 ~ 2 周的测试环境验证
  2. 灰度发布:先部署到少量实例,观察运行情况
  3. 监控关键指标:数据库连接数、查询性能、错误率等
  4. 制定回滚预案:确保出现问题时可以快速回滚

六、总结与建议

6.1 哪些团队适合选择 Microting?

如果你符合以下大部分情况,那么从 Pomelo 切换到 Microting 是一个值得考虑的选择:

  • ✅ 希望尽快升级到 .NET 10 LTS,不想等待 Pomelo 的更新
  • ✅ 使用 MySQL / MariaDB 作为主数据库
  • ✅ 项目升级计划不希望因提供程序版本而推迟
  • ✅ 项目中没有深度依赖 Pomelo 特有功能的第三方库
  • ✅ 团队能够接受从社区驱动转向商业公司维护的提供程序

6.2 哪些情况可以继续使用 Pomelo?

如果你符合以下情况,可以继续使用 Pomelo,等待其官方支持 EF Core 10:

  • ⏸️ 项目仍在 .NET 8 / EF Core 8 上运行良好,暂无升级计划
  • ⏸️ 对稳定性和成熟度要求极高,希望继续使用经过更广泛验证的方案
  • ⏸️ 深度依赖大量基于 Pomelo 的第三方库
  • ⏸️ 时间充裕,可以等待 Pomelo 官方支持 EF Core 10 后再升级

6.3 迁移复杂度评估

好消息是:这次迁移的复杂度相当低。

评估维度 复杂度 说明
代码修改量 ⭐☆☆☆☆ 极低 主要是命名空间替换
功能风险 ⭐⭐☆☆☆ 较低 同宗同源,功能基本一致
测试工作量 ⭐⭐⭐☆☆ 中等 仍需全面测试确保无回归
第三方兼容 ⭐⭐⭐☆☆ 中等 取决于项目依赖的第三方库
回滚成本 ⭐☆☆☆☆ 极低 反向操作即可回滚

总体而言,这是一次低风险、低成本的迁移。最大的不确定因素是第三方库的兼容性,而这取决于你的具体项目情况。

6.4 写在最后

Pomelo 作为 .NET 生态中最主流的 MySQL EF Core 提供程序,为社区做出了巨大贡献。作为社区驱动的开源项目,Pomelo 由志愿者维护,版本发布节奏相对稳健。Microting 的出现,为开发者提供了另一种选择——它专注于快速跟进 .NET 版本,让希望尽早升级的团队能够及时用上新版本。

对于希望尽早升级到 .NET 10 的团队来说,Microting 提供了一条低门槛的路径。而 API 的高度兼容性,意味着你随时可以根据情况选择继续使用 Microting、迁回 Pomelo,甚至在两者之间灵活切换。

技术选型从来不是非此即彼的单选题。了解每个选项的特点,根据自身情况做出最合适的选择,才是最重要的。


参考资料:

目录
相关文章
|
3天前
|
云安全 人工智能 运维
阿里云SecOps Agent,全新安全跨产品执行体验
自然语言驱动 云安全中心/WAF/CFW/ 等多款安全产品联动
1592 2
|
3天前
|
机器学习/深度学习 人工智能 调度
🐴 HappyHorse 1.1 现已上线阿里云百炼!快来查收模型使用指南,现在调用享 6 折~
HappyHorse 1.1 是新一代视频生成大模型,全面升级动态表现力、角色一致性、指令遵循、视觉质感与音画协同能力。支持I2V/T2V/R2V三类生成,适配短剧、电商广告、品牌营销等场景,提供高质、流畅、可控的AI视频生产力。
557 3
🐴 HappyHorse 1.1 现已上线阿里云百炼!快来查收模型使用指南,现在调用享 6 折~
|
14天前
|
缓存 测试技术 API
Qwen 3.7 Plus 与 Max 实测:性价比与多模态能力差异解析(2026)
2026 年 6 月 1 日,阿里悄无声息地发布了 Qwen 3.7 Plus,距 Qwen 3.7 Max 上线刚好 11 天。同样的 1M 上下文,同样的 35 小时自治上限。但价格才是头条:Plus 是 0.40/M输入,Max是 2.50/M——便宜约 6 倍——并且还能看图、看视频。Vision Arena 上 Plus 已经排到 #16。所以这周真正值得讨论的问题不是”要不要为视觉能力买单”,而是”Max 凭什么用 6 倍价格换来 2 个百分点的 benchmark 领先”。
|
15天前
|
JavaScript 定位技术 API
CodeGraph 爆火:编程 Agent 需要的不是更多上下文,而是一张提前画好的代码地图
CodeGraph 是一款爆火的本地代码智能工具,通过 tree-sitter 解析 AST 构建结构化知识图谱(存于 SQLite),为编程 Agent 提前生成“代码地图”。它显著降低 Agent 在中大型项目中的探索成本——实测工具调用减少71%、Token 降57%、速度提升46%,支持19+语言及主流框架路由识别,完全离线、无需 API Key。
899 11
CodeGraph 爆火:编程 Agent 需要的不是更多上下文,而是一张提前画好的代码地图
|
2天前
|
人工智能 监控 前端开发
Electron 监控:让桌面 Agent 监控触手可及
一行代码实现Electron桌面端全景监控,自动还原崩溃现场、预警内存泄漏、全链路追踪、 SSE流式响应与交互埋点,让 AI 助手运行状态清晰可见,助力快速恢复稳定与流畅。
177 125
|
2天前
|
消息中间件 人工智能 Kafka
AI 时代,实时入湖正在告别 ETL:从 Kafka 到 Iceberg 的架构减法
本文围绕“零 ETL”这一趋势,讨论流数据入湖为什么需要做架构减法,并结合 Kafka × Table Bucket 的实践,分析一种将通用入湖能力前移到消息与表存储链路中的方案,如何在降低复杂度的同时,兼顾实时性、一致性、Schema 演进、CDC 语义与开放生态兼容。
182 121
|
7天前
|
缓存 人工智能 运维
GLM 5.2自托管全流程实战:硬件选型、vLLM/SGLang部署与成本盈亏测算
2026年智谱发布GLM 5.2超大混合专家模型,区别于以往仅开放API的闭源大模型,该模型权重以MIT开源协议对外发布,企业与开发者可完整下载、本地审计、私有化部署,实现数据不出环境、自定义微调、自主调度推理资源。GLM 5.2拥有753B总参数,原生支持百万级上下文窗口,在代码生成、长文档推理、数学逻辑等多项基准测试中对标国际顶尖商用模型,是首款可完整自托管的前沿代码向大模型。
613 0
|
15天前
|
人工智能 运维 JavaScript
阿里云Qoder CN(原通义灵码)全解析 产品形态、版本划分与技术适配说明
在AI辅助开发与智能办公工具持续普及的当下,阿里云旗下原通义灵码正式更名为Qoder CN,同时延伸出QoderWork CN、Qoder CN CLI、Qoder CN Mobile等多款配套产品,形成覆盖代码开发、日常办公、终端交互、移动端使用的完整工具矩阵。Qoder CN核心定位为AI智能编码助手,深度适配主流代码编辑器、集成开发环境以及终端场景;QoderWork CN则偏向桌面端综合办公辅助,二者面向不同使用场景,划分了多个版本档位,搭配差异化资源配额、功能权限与计费规则,同时兼容多款主流大模型。
974 8