.NET 10 有哪些新特性？你对.NET 10 的计划是什么？是迁移还是暂缓？

.NET 10无疑是款稳健的版本，既堪称周年纪念版，亦符合长期支持版本的标准。开发者持续聚焦性能优化并保持标准库逐年更新的态势令人鼓舞。
💬 207 条评论 | |

终于！.NET 10 即将问世，是时候燃放烟花庆祝我们最喜爱平台的周年庆典了！本文探讨了即时编译器改进、标准库扩展、新 SDK 功能及其他创新特性。

元素周期表

.NET 10 重点提升性能与安全性——尤其是加密技术获得了重大优化。作为长期支持(LTS)版本，它将获得为期三年的技术支持。

本文仅涵盖库、运行时和 SDK 中部分重要且有趣的改进。毕竟一篇文章不可能详尽描述 .NET 10 的所有变更。

我们的团队已着手支持新版 .NET 10 和 C# 14——相关功能将随 PVS-Studio 7.40 版本发布。该版本计划于 12 月初推出，欢迎订阅我们的新闻简报以获取最新动态。

C# 14§

我们已在另一篇文章中全面介绍了C# 14的所有创新特性，包括扩展块、field关键字、模式匹配的改进等。值得特别指出的是，该版本还支持赋值时的?运算符。

在 C# 14 之前，为安全赋值需先检查变量是否为空：

if (user is not null)
{
    user.LastActive = DateTime.UtcNow;
}

如今等效代码可简化为：

user?.LastActive = DateTime.UtcNow;

这项创新减少了冗余代码，始终是值得欢迎的改进。

性能§

每次发布都让可靠的.NET平台变得更快。秉承传统，Stephen Toub已发布详尽文章阐述性能优化细节。

具体而言，变更涉及LINQ、正则表达式、加密算法、JIT、AOT、I/O等多项领域。

建议至少浏览原文以全面了解变更内容。

库§

加密§

System.Security.Cryptography 库现新增三种支持后量子非对称算法的类型：ML-KEM (FIPS 203)、 ML-DSA (FIPS 204) 以及 SLH-DSA (FIPS 205)。

.NET 10作为长期支持版本，添加后量子加密算法支持实属明智之举——随着“先收集数据，后解密”攻击手段的可行性逐年提升，此类攻击场景正日益现实。该攻击模式指攻击者截获并存储加密数据，待技术成熟时再行解密。

集合§

我们现已为TryAdd和TryGetValue 方法。新方法的唯一区别在于它们还通过out参数返回索引值。

序列化§

现在可配置序列化/反序列化过程中的循环引用处理方式。通过在JsonSourceGenerationOptionsAttribute中指定ReferenceHandler即可实现。

新增的JsonSerializerOptions.AllowDuplicateProperties参数可防止JSON属性重复。

字符串§

.NET 10 引入了新的 API，将规范化扩展到字符串类型之外。现有 API 仅适用于字符串类型，因此其他形式的数据(如字符数组或跨度)必须转换为字符串。现在无需如此：新 API 允许您直接处理字符范围。

还新增了 UTF-8 字节序列与十六进制表示之间的转换方法，无需分配中间字符串。这些方法重载了仅适用于string和ReadOnlySpan<char>的现有实现，但通过直接操作UTF-8编码字节，提供了更高的性能。

此外，作者新增了NumericOrdering选项，用于指定字符串比较应采用数值排序而非字典排序。在此模式下，字符串“2”将与“02”视为等价。

运行时§

AVX10.2支持§

新版框架新增对x64架构处理器的AVX10.2指令支持。需注意支持AVX10.2的处理器将于明年发布，因此该功能需待硬件就绪后方能进行全面测试。

我们正期待着它的发布！

小型数组栈分配§

.NET 10 为值类型和引用类型的小型数组引入栈分配机制。当JIT确定数组数据的生命周期不会超出创建上下文时，该数组将分配在栈上。此变更旨在减少垃圾回收器需追踪的对象数量，从而降低GC负载并为未来优化创造空间。

请看以下示例：

static void Sum()
{
    int[] numbers = {1, 2, 3};
    int sum = 0;

    for (int i = 0; i < numbers.Length; i++)
    {
        sum += numbers[i];
    }

    Console.WriteLine(sum);
}

包含三个整数的numbers数组将被分配在栈上，因为编译器知道该数据的生命周期在Sum方法退出时结束。引用类型的数组同样适用此规则。

static void Print()
{
    string[] words = {“Hello”, “World!”};
    foreach (var str in words)
    {
        Console.WriteLine(str);
    }
}

与前例类似，words数组的生命周期仅限于Print方法内部，因此编译器将其置于栈上。

写屏障垃圾回收§

众所周知，.NET垃圾回收器采用分代模型，根据对象在内存中的存活时间管理堆内存。这使得特定代的对象能快速回收。但若年轻代的引用意外进入老年代，就会引发问题——扫描年轻代时，老年代不会被扫描。

为避免此类情况，系统采用写屏障机制追踪跨代引用。

但从编译器性能角度考量，最佳写屏障方案是完全不使用写屏障。

.NET 10 还修复了部分 GC 写屏障问题，从而提升了性能。

JIT 改进§

.NET 10 对 JIT 编译进行了重大增强，旨在全面提升性能。改进包括：优化内联处理、改进结构体成员的代码生成、消除数组枚举抽象等。

SDK§

包引用移除§

自 .NET 10 起，NuGet 审计功能可移除未使用的包引用。此创新同样聚焦优化：它减少了构建过程中需要恢复和分析的包数量。

该功能将默认启用在所有目标为 .NET 10 及更高版本的项目框架中。

MSBuild§

在 Visual Studio 或通过 msbuild.exe 运行的 MSBuild 是 .NET Framework 应用程序，而在 dotnet CLI 中运行的 MSBuild 则是 .NET 应用程序。这意味着任何为 .NET 编写的 MSBuild 任务，由于环境差异，在 Visual Studio 构建或使用 msbuild.exe 时均无法使用。

从 .NET 10 开始，Visual Studio 2026 和 msbuild.exe 将支持运行为 .NET 构建的 MSBuild 任务。现在无论在 Visual Studio 中构建，还是通过 dotnet CLI 使用 msbuild.exe，均可使用相同的任务。此变更消除了为不同框架重复重写和持续维护 MSBuild 任务的需求。

新增命令§

新增的 dotnet tool exec 命令允许在无需全局或本地安装的情况下执行 .NET 工具，这对 CI/CD 流程尤为实用。

此外新增的 dnx 脚本提供了简化的工具执行方式，它将所有参数重定向至 dotnet 命令行界面进行处理。

随着.NET 10的发布，我们还可以通过‑‑cli-schema参数检查命令行界面。使用该参数时，它会输出被调用命令或子命令的CLI命令的JSON树结构表示。

无需项目即可运行单个C#文件§

现在可基于单个文件创建应用程序而无需项目，简化了程序创建与执行流程。操作时只需对单个*.cs文件使用dotnet run命令。开发者认为此方法适用于创建小型命令行工具、原型及各类实验项目。

所有基于文件的应用程序默认支持原生AOT编译，并可通过dotnet publish发布为原生可执行文件。

总结§

综上所述，.NET 10无疑是款稳健的版本，既堪称周年纪念版，亦符合长期支持版本的标准。开发者持续聚焦性能优化并保持标准库逐年更新的态势令人鼓舞。

本文仅列举了我们认为最值得关注的创新点。完整改进列表请参阅此处。若您发现本文遗漏的重要或有趣变更，或对.NET 10有任何见解，欢迎在评论区分享——期待您的反馈。

现在，让我们共同庆祝这个周年纪念日吧 🙂

元素周期表抱枕

共有{207}条精彩评论

  1. 我们使用Docker，项目相对简单。迁移只需更改标签并确保测试通过即可。没有理由不这么做。

    回复

    1. 瞧瞧这位装腔作势的家伙…

      转身回到满屏.NET Framework 4.8项目的另一台显示器前，继续默默流泪

      回复

      2. 同感。我们团队维护着约400个不同Web应用，多数在4.8环境，部分仍用老旧Web Forms(幸好最后那个Perl应用已重写)。迁移之路注定漫长而痛苦，但我们正全力以赴。

        回复

        1. 我们公司情况类似。数百个应用程序，其中大部分居然还在4.6版本上运行，还有WCF，很多破事还得交给该死的主机系统处理。

          我们团队周一要开会讨论应用程序的未来，从当前简单的升级到4.8.1版本，到可能彻底重写。应该会很有意思(我其实真心期待这次讨论)。

          回复

        2. 目前处境相同(500多个项目)。底层架构已开始迁移，但通往自由的道路漫长。

          回复

          1. 这种规模下，你们连NuGet更新这种基础操作都怎么处理？

            回复

            1. 我无法代表/u/Ok_Inspector1565，但我们通常在项目有改动时或出现重大漏洞时更新包。绝大多数项目每年至少会进行一次维护。

              我们仍有几个遗留应用在使用Telerik框架，每次出现重大漏洞时，更新所有组件都极其麻烦。

              我们正在推进遗留应用的重构工作，但这需要耗费大量时间。

              回复

            2. 我们的做法类似，通常只在绝对必要时更新。环境变更涉及复杂的治理流程，实在令人头疼，因此变更推进缓慢。

              回复

      3. 我运行的是4.8和标准2版本，因为开发人员只想开始开发新功能。

        回复

        1. 赶紧升级吧，体验好太多啦

          回复

        2. 难道他们不能在.NET 10上开发新功能吗？

          回复

          1. 若需与框架应用交互就行不通。

            回复

      4. 感同身受。我们正迁移到.NET 8，问题在于有700张数据库表，其映射和连接API都是手动生成的，且全部基于WCF构建。现在我们(其实只有我)正在用REST和gRPC API调用替换它们。

        这就是企业软件的症结所在。除非万不得已，否则绝不改变。这次改造纯粹因为客户要求特定证书，而这些证书需要相应的安全特性支持。

        回复

      5. 要不要组建互助小组？我实在无法独自承受这份煎熬了。

        回复

      6. 真羡慕啊。我还在维护4.6.2版本呢。

        回复

        1. 这话题值得尽快讨论，毕竟4.6.2将在2027年1月达到生命周期终止。

          回复

          1. 作为曾经的4.6.2项目负责人，问题要么是依赖关系(旧版Office API)，要么是保守升级心态(过去升级搞砸过，现在不敢冒险)。

            遗憾的是这类人通常不在乎支持终止。

            回复

      7. 实际上，虽然大家都在讨论.NET最新版本，但现实中极少有公司追随最新发布。我们多数应用仍运行在.NET Framework上。其实现在正是用.NET 10将遗留应用迁移至现代.NET架构的好时机。可参考开源的ABP框架https://abp.io

        回复

    2. 我职业生涯中大部分时间都在使用.NET，迁移过程通常只需升级框架版本号即可。虽然会出现一些新警告(多为过时内容)或轻微破坏性变更，但这些问题通常能快速解决

      回复

      1. .NET 10确实引入了些棘手的破坏性变更。开始一小时任务前请务必确认 🙂

        回复

    3. 10需要最新版的Debian系统。具体版本记不清了，但操作系统版本差异导致我遇到问题或缺少依赖项

      回复

    4. 我的项目仍在开发中，预计不会有太多阻碍我切换标签/版本的因素。虽然我几乎没用到.NET 9特性，但目标平台应该已指向.NET 9。

      回复

      1. 不过你可能已在不知不觉中受益于某些性能优化。

        回复

    5. 呃…上次把十几个老应用(包括一个超大单体应用)从4.7升级到.Net 6时，我也只改了版本号标签。😏 好吧，三年过去了，这些系统连一个“新”特性都没用上，但至少… 接下来几个月要迁移到.Net 10了，真希望这次能拨出资源重构几项代码…

      回复

  2. 卧槽！我们还在用.NET 4.7.2的WebForms

    回复

    2. 我同时用着4.6、4.7、4.8和8 🫠

      回复

      1. 4.6项目的时钟正在滴答作响 😬⏰

        回复

        1. 连8.0版本也将在2026年11月10日“停止支持”

          回复

    3. 我们全版本都有！😅

      4.7.2、.NET 6、.NET 8、.NET 9，10.0也即将上线。

      回复

    4. 我负责的某些项目里还用着VB.NET😂。最近刚升级到.NET Framework 4.8。

      回复

      1. 我是说 某些 人还在积极使用VB.NET并瞄准10版

        回复

    5. 从 .NET Framework 迁移到 .NET(当年还是 Core)是最“艰难”的迁移。尤其我们当时用的是 IIS，还想迁移到 Kestrel。但之后每次更新其实都不算太难，主要是测试环节。我们还通过消息总线使用小型服务，所以可以逐个迁移部署，不过开发端我们采用单仓库模式，所以所有迁移都是同时进行的。

      回复

    6. 同感。活化石般的恐龙🦖

      回复

    8. 哈哈哈我3.1版本里还有个老古董😅最新才到7…是时候全升级到10了

      回复

    9. Blazor和Copilot或许能解决这个问题？

      回复

    11. 希望你们准备好在万圣节派发威瑟原味软糖了。

      回复

    12. 真可惜，从WebForms迁移到MVC可是最棒的QoL改进之一。MVC在2009年随3.5版本推出时可是最新技术。抱歉，我觉得你们开发团队很差劲。WebForms就是垃圾。我们团队虽小，但维护着几十个应用，完全能搞定。

      回复

  3. 上线后几周内我们很可能从.net9迁移到10。基于Linux的完整容器化平台让我们轻松应对。最坏情况也能用k8s快速回滚，不过我怀疑根本用不上。

    回复

    1. 在Windows环境下使用容器会不同吗？

      回复

  4. 迁移(从8版，LTS=>LTS)但不急于实施。需给库文件在新版本中稳定的时间。或许圣诞节后再行动

    回复

    1. 同上，我们通常在1月进行。

      回复

    2. 同样如此。我们通常会等待一到两个补丁版本发布。

      回复

        1. 为什么？为何不每次升级以获取版本间的性能优化？保持与最新版同步比每两年才升级更能避免大爆炸式迁移

          回复

          1. 正如我之前解释的。这些功能很少是我需要的。即便性能提升，对我当前的工作负载而言也微乎其微，根本无关紧要。

            我从2004年就是.NET开发者。Reddit能否理解，当我说不需要每年更新.NET SDK时，我确实知道自己在说什么？

            新版本带来收益固然好，但并非人人如此。

            两种观点都合理正确，没必要反复纠缠争论。

            回复

    2. 若你使用.NET 8，那么.NET 9将在完全相同的日期停止支持。我认为现在没有理由不升级到STS版本。STS版本现在都将获得支持直至前一LTS版本的发布日期，这是非常明智的举措。

      回复

      1. 存在重大阻碍：若你的EF Core驱动程序不支持EF Core 9.0/10.0版本。

        Pomelo mysql近期才开始支持9.0。企业因应用安全和法律团队限制，无法使用任何预发布/测试版软件。

        回复

        1. 好奇问一句：除了“创业时用惯了，现在迁移成本太高”之外，2025年还有什么正当理由继续使用MySQL？

          回复

          1. 我们的DBA/运维/基础设施团队只懂支持MySQL/Galera，其他方案一窍不通。

            遗憾的是，从一个免费数据库迁移到另一个免费数据库并不能解决实际问题。

            回复

            1. 没错，但继续使用支持差的数据库反而会增加成本。

              回复

            2. 我不知道，它能满足我们的需求，运行得完全正常。

              我个人其实更喜欢Postgres，特别是它的事务性模式变更功能，但似乎只有我这么想(在我们公司)。

              编写新的迁移、扩展、备份、恢复、灾难恢复流程，学习各种ANALYZE输出和性能分析器…我实在想不通，任何拥有15-20年历史数据库架构的企业，升级到其他关系型数据库管理系统究竟能获得什么好处

              回复

          2. 客户自行托管数据库，而你二十年前销售时承诺支持这些数据库，因此无法直接要求他们切换到完全不同的数据库类型。我们只能满足于每隔几年强制他们升级数据库版本。

            回复

            1. 确实，这属于“创业初期就用它”的典型案例。但我想问的是：到了2025年，为何还要选择任何MySQL(/MariaDB)变体而非PostgreSQL？

              回复

            2. 老实说我实在想不出理由。或许过去MySQL比PG的优势在于复制功能简单易用，但据我所知PG如今已大幅改进，这个优势已不复存在。

              话虽如此，若由我做主，绝对选PG。

              回复

            3. 所以你不能直接要求他们切换到完全不同的数据库类型。

              当然可以… "2028年我们将终止对MySQL数据库的支持，届时仅支持PostgreSQL(或其他选定数据库)。为确保平滑过渡，我们将为需要迁移的客户提供迁移工具与技术支持。我们相信采用现代、快速、可靠且跨行业广泛支持的数据库系统，将使我们持续为客户提供世界级软件产品。"

              至于实际成本效益如何，则是另一个问题了。

              回复

            4. 哦，我们得迁移了。既然必须迁移，那我们得看看竞争对手能提供什么方案。除非你们愿意为我们的麻烦提供数百万美元的折扣。

              这种事短期内不可能发生，除非我们能证明某些事情根本无法实现。不同行业运作模式各异，有些情况你只能接受。

              回复

          3. 我的意思是，MariaDB在2025年依然是个不错的选择，而且你需要MySQL适配器才能连接它

            回复

            1. 相比PostgreSQL，它凭什么算“不错的选择”？

              回复

        2. 具体到EF Core，你可以升级.NET版本，但继续使用旧版EF Core。

          比如EF Core 7或8在.NET 9上运行完全没问题。预计.NET 10也会如此。

          我们之前就这么干过，因为当时卡在旧版npgsql上。

          回复

          1. 真希望驱动程序能兼容新版EF Core——可惜它依赖某些EF特性导致不兼容，兼容性修复耗时过长

            回复

            1. 你没看清回复对象吗？.NET运行时版本与EF Core版本无关，两者可独立升级。

              回复

      2. 我们需要为客户开发实际功能，当前所有组件的更新量已让我们无暇分身，除了更新和回归测试别无他法。

        我知道回归问题应该不多，但若直接部署完整版本更新，公司流程要求必须进行全面回归测试。

        我们并非单一.NET应用，而是拥有多个.NET应用，配有多个前端界面，运行在多台服务器上。

        回复

      3. 确实，理由充分。这样就能避免年复一年地处理这些问题。除非涉及功能更新之类的情况，否则真的没有必要做。两者都处于支持阶段，若无法带来切实收益且没有实施必要，就没必要做。

        回复

        1. 每个项目情况不同，但我们升级从未遇到过问题。开发工作量约30分钟，我们利用空闲时间或维护周期，每天逐步升级一个应用。

          回复

      4. 若.NET 9在同日期终止支持，则无需升级至该版本。

        回复

        1. 除非你想使用新特性或性能优化。

          回复

      5. 理由依然存在——我就是不想升级。若能选择，我宁愿继续用旧版本更久。

        回复

            1. 不是。只是新功能或变更中很少有我需要的。定期出现的只有破坏性变更，最明显的是EF Core查询的破坏性变更。所以最终，.NET更新对我或客户而言都是额外工作，没有直接收益。

              追逐尖端技术的日子早已过去。我现在是个老开发者了。

              回复

            2. 我不认同客户毫无收益的说法。最新版本确实带来显著性能提升，更高效的应用意味着更低的计算成本。客户要么获得性能更优的应用，要么降低成本，甚至两者兼得。

              回复

      6. 看来有人从未在效率低下的大企业工作过啊！

        在我们这家员工超八万的公司里，我总得反复提醒大家：

        千万别升级到.NET的STS版本

        为什么？

        因为我们是金融公司，行动速度堪比三岁小孩每隔30秒擤鼻涕时鼻涕从鼻孔掉落的慢速。

        我们有各种各样的规则。“代码必须通过Fortify SCA扫描才能投入生产！”

        “大人！Fortify比现代软件的生命周期落后1.5年！它只能扫描已停产超过1年的软件！”

        “竟敢用逻辑质疑！将.NET Framework 2.0刻成石板奉为圭臬，驱逐那些使用Linux这类巫术和'跨平台'黑魔法的异端！”

        回复

    3. 补充说明：他们将STS支持周期延长至2年，且追溯至.NET 9版本。

      回复

      1. 现在转9版太迟了，但明年肯定会升级到10版再到11版

        回复

      2. 没错，此举的主要好处大概就是解决“启动新项目时该选哪个.NET版本”的疑问。

        既然STS版本的生命周期与前代LTS版本一致，无论是否LTS，答案永远都是最新版本。我个人很赞同这个方案，因为实在厌倦了向他人解释如何区分版本，现在只需告诉他们“新项目直接用最新版”就行。

        回复

    4. 我们的计划是：继续使用LTS版本，偶尔在非主流版本中进行概念验证以探索新功能

      回复

    5. 迁移。我始终坚持使用LTS版本。

      贵团队需要什么条件才会从LTS转向当前版本？

      回复

    6. 我们曾只迁移至LTS版本，但后来发现随每个版本迁移更轻松。微软内部许多人后悔实施STS和LTS模式。随版本迁移更优——在增量版本中处理的破坏性变更更少，而非在LTS版本间跳跃，至少这是我们的经验。

      回复

  6. 立即迁移。我的项目已运行在预览版上，一切运行顺畅。况且这是LTS版本。

    回复

  7. 我们总会等待一个季度，确保所有关键包完成适配。这也意味着若首月出现问题，圣诞假期期间大量开发者休假时就不会影响我们。

    回复

  8. 何必迟疑？历代.NET都带来过重大性能提升

    回复

    1. 近年唯一阻碍是Dynatrace与.NET 7兼容性问题(记得是从6升7时)。

      除此之外，除非存在某些罕见的依赖关系阻碍，否则实在想不出拖延的理由——除非十二月有发布冻结期导致无法及时完成。

      回复

      1. 兄弟，我完全懂你的感受！💗

        是时候找个更好的公司了，那里的人真正热爱工作，不会如此缺乏安全感。

        回复

  9. 升级吧。何必等待？那只是把眼前的痛苦推迟到未来承受更多痛苦。每天吃蔬菜锻炼30分钟，就能避免将来中风。道理很简单。

    回复

  10. 管他呢兄弟，人生本就充满风险。

    我第一天就升级。系统崩溃？那叫工作保障。

    回复

  11. 明年三月迁移，等第三方库全部更新，10.0.1版本发布并修复初期问题后。

    回复

  12. 迁移。正如几位提到的——升级很简单。而且我想要封闭枚举

    回复

    1. 我认为封闭枚举(或其他区分联合相关功能)不会出现在本次发布中，但.NET 11应该会有相关支持，前景很乐观。

      回复

    2. C#的枚举不是默认封闭的吗？我从未尝试过扩展枚举，也没见过有人这么做。

      回复

      1. 在语言提案中，闭合枚举的闭合性并非指继承关系，而是强制要求底层整数值必须属于枚举定义的取值范围。

        例如：

        closed enum pet : int

        {

        cat = 1,

        dog = 2,

        rabbit = 3

        }

        pet mydog = (pet)2; // 有效。2 = dog

        pet other = (pet)4; // 无效。有效范围为1..3

        此机制有助于消除CS8524场景：“switch表达式未处理其输入类型的某些值…”

        回复

        1. 不过有个疑问：我从未见过枚举值这样实例化，也从未见过此类警告。

          既然可以直接使用…

          Pet mydog = Pet.Dog;

          为何还要将整型强制转换为枚举？

          我知道您为简洁起见提供了简单示例，但我实在难以想到实际应用场景。您遇到过类似情况吗？

          另外，感谢你的示例。我了解到Swift中closed关键字不等于@frozen。

          回复

          1. 当然——你提到的示例只是为了说明问题。它旨在展示编译器会阻止此类操作，而这些操作在'Open'枚举中原本是合法的。

            对我而言，确保枚举值始终为已定义类型能带来更强的安全感和保障

            回复

  13. 从4.7.2迁移至.Net 9已近尾声，若无重大障碍，将直接升级至10版。

    回复

  14. 问题并非出在.NET本身，而是数据提供商的兼容性滞后。Pomelo或Npgsql等驱动对EF Core 10的支持可能延迟数周，导致生产环境迁移受阻。我们发现dotconnect通常会随新EF Core版本同步发布更新，因此依赖MySQL、Postgres或Oracle的项目无需等待兼容性补丁即可提前迁移。

    回复

  15. 最可能在一个月内迁移。目前尚未遇到.NET新版本引发的问题，但某些游离依赖项可能存在隐患。

    回复

  16. 我们正经历长达数年的更新项目。当初从框架迁移到核心耗时过久，如今成了极其棘手的过程。多数功能尚可，但部分LINQ查询无法转换导致运行时失败，另有若干函数存在陷阱。教训是：必须更积极地跟进最新版本，这样变更幅度更小且更易处理。

    回复

  17. 我的项目大多仍基于旧框架，且无便捷迁移途径(嵌入式系统分散部署)。😢😿

    回复

    1. 去年(2024年！！！)有个项目，有人试探性提议从Framework 3.5迁移到4.2之类的版本。

      够大胆的吧？

      回复

      1. 接下来该从VB6迁移到vb.net了吗？？

        回复

  19. 我通常会等几个月，等尘埃落定再迁移。

    回复

  21. 我总会升级到最新版本，使用的库并非小众用途。

    回复

  22. 总先将次要项目即时升级作为测试平台。

    其余项目则随开发进度自然升级

    若需特定改进或依赖项要求，再行处理。

    通常数月内所有活跃项目即可完成升级。

    回复

  23. 升级前需全面核查Automapper、FluentAssertions等库的授权问题

    回复

  24. 我们将尽快迁移。现有500余个项目的单体架构，始终保持版本同步。

    回复

  28. 我们即将迁移，而且正在使用VS 2026！👍

    回复

  29. 我正在将框架4.8迁移到NET7。估计等到10版过时才会迁移。

    回复

  30. 我们已开始测试RC版本，在.NET(Core)中更新毫无顾虑——除非遇到依赖项在新版本中失效的罕见情况(目前尚未遇到)。

    从LTS升级到LTS平均最多耗时3小时，STS到LTS约需1小时(反之亦然)。

    回复

  31. 立即升级，测试无误后推送至生产环境。人生苦短，及时行乐。

    我们团队规模小，无意支持“遗留”软件，因此每年都会将十余个应用升级至最新版本。这种做法已持续十余年。

    回复

  32. 感谢您的发帖，Volosoft。请注意我们禁止垃圾信息，请遵守侧边栏规则。常见问题已收录于搜索功能，若本帖被移除，请先检索是否已有相关讨论。

    本操作由机器人自动执行。如有疑问请联系本子版块管理员。

    回复

  33. 通常版本发布时迁移很顺利，只是Rider需要更长时间才能完全兼容。

    回复

  34. 建议迁移，但我们其中一个主项目需要大量工作才能完成(因内部异常远程传输使用了BinaryFormatter)。

    回复

  35. 公司计划新年期间从.NET 8迁移至10。

    他们主要使用LTS版本。

    .NET 9项目将按相同周期更新。

    回复

  38. 我所在团队仍使用.NET 8，但已计划迁移至下个LTS版本。我已整理出代码变更清单，以便充分利用新功能。

    回复

  39. 一如既往：选个影响小的服务，升级版本，构建镜像，火速推到生产环境看看效果。要是没问题，剩下的操作大概当天就能搞定。

    等库文件和Docker镜像准备就绪，Renovate会立刻在我们的PR屏幕上亮起来。

    回复

  40. 唯一记得遇到迁移问题的，是多年前从1.0升级到2.0时。当时配置方式有几处破坏性变更，但影响都很小。

    回复

  41. 操作如此简单，不做才不值得。

    回复

  42. Migrate-Maui需更新才能支持最新操作系统版本

    回复

    1. Android API 36不会出现在.NET 9？这很棘手。

      回复

  43. 我一直渴望拥有C#脚本语言，而PowerShell虽功能强大，但自PowerShell 7起作为跨平台工具，本质上已是截然不同的语言范式。

    因此我期待C#脚本时代的到来。

    关于编译型解决方案，我将在.NET 10发布首月内完成迁移，同时验证能否可靠地将其迁移至Ahead-of-Time(AOT)编译模式。

    回复

  44. 等待10.0.1版本修复回归性缺陷后再升级。

    回复

  45. 主项目通常会升级到最新.NET版本，但分支项目总让我头疼不已 🙁

    回复

  46. 同时支持带Docker和不带Docker的迁移方案。

    回复

  48. 我们使用MAUI平台运行.NET 8，别无选择。微软会火速抛弃旧版本支持，连JetBrains也开始忽视旧版本的问题。

    我们已建立可运行的.NET 9分支，理想情况下会尝试迁移至.NET 10。若难度过大，下个版本仍将维持.NET 9。但时间紧迫，迁移势在必行。

    回复

  49. 我仍在使用.NET 6，8.0发布时因6.0仍在支持期未迁移，9.0发布时又因10.0临近而未升级。

    所以这次大概会更新。我很喜欢新增的单文件程序功能，特别适合“Hello World”类型的项目。

    回复

  50. 我只在LTS版本发布时升级…目前Windows项目用.NET 8，移动端用.NET 9(受Google Play SDK要求限制)

    回复

  51. 已启动迁移，约30%的服务已在生产环境运行.NET 10。RC1版本(附带正式部署许可)发布时，我们采取了循序渐进的控制性部署策略。

    回复

  52. 每次版本更新都带来性能提升，迁移过程基本无痛。我们正立即进行迁移。

    回复

  53. 客户技术要求我们保持系统适度更新，且必须使用持续获得安全补丁的框架和库。

    因此我们很快就会迁移。

    回复

  54. 所有“现代化”项目将在第一季度末前迁移至net10。

    遗憾的是，仍有大量项目停留在4.8 MVC/WebForms版本，而迁移至现代.NET的途径依然糟糕得可笑，几乎等同于“全部重写”。官方指导建议“使用AI转换”的做法，恰恰暴露了其认知之浅薄。

    回复

  55. 因组织限制暂缓推进。当前8个项目

    回复

  56. 当然要尽快迁移。想立刻用上那些炫酷的新扩展。

    回复

  57. 发布后立即升级。我们支持LTS版本，总在支持终止前完成迁移。

    回复

  58. 迁移是因为这是LTS版本，更新过程应该和上次一样轻松。

    回复

  59. 我们遵循LTS版本升级策略，当前使用8.0将升级至10.0。预计仅需修改少量标签，若启用“将警告视为错误”功能导致警告提示，可能需稍作调整。

    回复

  60. 我们已将代码库从.NET 8迁移至.NET 10。EF Core的命名查询过滤器正是我们急需的功能。虽然尚未投入生产环境，但大部分准备工作已就绪，使用体验令人满意。

    回复

  61. 我始终将项目迁移至最新版本。除非需要微软的延长支持周期(我们并不需要)，否则LTS与STS版本并无实质差异。

    我通常不碰预览版，但由于VS26预览版搭载了.NET 10预发布版本，我测试了.NET 10的新逻辑排序功能。因此我已准备好一个基于.NET 10的分支，随时可用于正式发布。我还发现并修复了Blazor交互功能在.NET 10上失效的问题(可能是某个Blazor脚本略有改动？)。

    因此当.NET 10正式发布时，我只需在Azure上切换运行时环境，合并分支并推送至主仓库即可。

    当然，NuGet包有时会包含破坏性变更，但这种情况可能随时发生，与目标框架无关。正因如此，我始终确保所有依赖项都保持定期更新。

    根据我的经验，升级工作拖得越久，情况就越糟。我宁愿一次性完成所有项目的升级，以免忘记需要修改的内容。

    回复

  62. 我们已准备好使用RC2标签的基础镜像，因此正式发布首日只需将标签切换为GA版本，各产品线更新基础镜像标签后即可完成构建、测试和部署。

    回复

  63. 肯定会升级。主要是为了跟上整体生态系统的步伐。我们这个相对简单的akka.net应用应该很容易完成升级。

    回复

  64. 待库兼容性问题解决后立即迁移(可能在正式发布前就完成)。

    这本质上是免费的性能升级。去年从8版迁移到9版时，相同工作负载下的CPU占用率立即下降。

    回复

  65. 遗憾的是我们仍将维持8.0版本，至少目前如此。其他开发者今年刚从Framework迁移过来，现在正沉浸在功成名就的喜悦中。

    回复

  66. 更新global.json文件后就无需再操心

    回复

  68. 迁移速度很快。只需等待Rider和playwright提供支持即可。

    回复

  69. 软件技术的僵化是亟待解决的问题，而非值得称道的优点。

    回复

  70. 预览版分支已准备就绪。正式发布后我们会更新分支，进行额外测试，很可能在圣诞节前发布。

    回复

  71. 等版本发布且Rider开始支持后我就迁移。特别期待新EF功能——更强的JSON支持和命名查询过滤器

    回复

  72. 我们刚把首个服务从6版迁移到8版。但看到日期后发现，不如再等一个月直接升级到10版。

    回复

  73. 我正在处理中。除了EF Core的破坏性变更外没遇到问题，不过影响不大，我暂时搁置了该包的升级。

    回复

  75. 所有团队都迫不及待想升级，CTO也是，估计发布当天下午我们就会成为.NET 10团队了🤷

    我并非抱怨，只是有点意外这次新版本发布时最激动的不是我。

    回复

  76. 对新GC特性非常期待。等npgsql支持EF10我就立刻迁移

    回复

  77. 反正新项目就直接跳进去吧，毕竟大家都知道我们正面临越来越快的淘汰周期。现有项目是否迁移是个更深层的问题，取决于你打算维护多久。如果能让它随着当前.NET版本的淘汰自然消亡，那就无需动它。

    回复

  78. 我绝对会迁移。为什么？如果.NET 9完美无缺，就不会有.NET 10了。

    回复

  79. 预览版刚发布我就迁移到.NET 10了，遇到过第三方库和某些设备上AOT编译的问题，但都解决了，至今运行良好。

    回复

  82. 我们仍在使用.NET 4.7.2 WPF。我正在开发.NET 8版本，但其中存在若干BinaryFormatter的用法需要迁移支持。由于部分客户常跳过一两个版本升级，我无法让最后的.NET 4.7.2版本实现这些用法的迁移。

    回复

  83. 请立即创建安全分支或标签进行迁移，原因有二：既能受益于安全修复和性能优化，又能规避用户因“系统运行良好”而抵制升级的风险——若后期强制升级可能引发问题。这种情况在任何技术领域都可能发生，Java用户常固守旧版本(至今仍有Java 8系统在运行)。在.NET领域，部分用户仍使用.NET Framework运行系统。虽然从4.5迁移至10版可能存在复杂性，但无需让问题持续累积。若遇故障可回滚至原版本。若追求更稳妥的方案，可等待年底发布——届时运行时、编译器及第三方库中的多数漏洞都将浮出水面。

    回复

  84. 大概在1月。微软总爱在第四季度发布这些更新，而物流环节向来遵循“四季度禁动”原则

    回复

  85. 可能要等到发布一个月后，当.NET 10成为Azure函数和应用服务等资源的可用选项时

    回复

  86. 永远要迁移。忍痛动手吧。若不行动，下次只会更痛苦。

    回复

  87. 2026年第一季度或第二季度初，当LTS版本到期时。

    回复

  88. 既然是LTS版本，我肯定会提前迁移。除了少数几个项目(这些项目在.NET 10发布前都不会推出初版)，我们基本跳过了.NET 9。

    不过挺有意思的是，我们同时会运行.NET Framework 4.7.2、.NET Framework 4.8和.NET 10。

    回复

  89. 我发现保持在.NET LTS支持版本上，既能获得定期性能优化，又不会过度陷入版本迭代的漩涡。无论做什么项目，你都应该坚持使用受支持的技术栈，而LTS版本恰恰提供了这种保障。

    回复

  90. AWS Lambda支持10版后，我们将立即从8版迁移至10版。Blazor前端也将从9版快速升级至10版。

    回复

  92. 上周将某个项目升级到.NET 10，结果在Azure DevOps无法构建，只得回滚到9。不确定是我的操作有误，还是最新镜像尚未包含该版本。

    回复

  93. 建议等待1-2个月再迁移。给系统留出完善时间，确保依赖项更新到位。

    回复

  94. 工作中仍有部分.NET 2和.NET 3.5应用在运行。x) 个人项目(主要是移动端)计划圣诞节前后迁移至.NET 10。

    回复

  95. 除非有充分理由使用非LTS版本，否则我始终坚持使用LTS版本。
    同时也会尽快完成更新。

    通常破坏性变更很少，只需升级csproj文件、更新Docker镜像，并确保管道构建使用新版SDK即可。
    通过Flagger发布版本，大功告成。

    虽然涉及大量项目/部署，但都是小工程。

    回复

  96. 我会等首个补丁发布后再迁移

    回复

  100. 没什么，我们用.NET做的项目大多还是基于.NET Framework。没错，这就是当系统不完全兼容时的情况——企业宁愿不花钱迁移，继续用现有的方案。

    像Sitecore和Optimizely这样的.NET内容管理系统巨头，已将其SaaS产品及定制化方案迁移至.NET之外，这进一步缩减了我们在项目交付中使用.NET的场景。

    工作中接触现代.NET的寥寥几次，要么是部署上述CMS这类Azure函数，要么是代理机构的内部项目。

    回复

  101. 一如既往的策略：维持现状，继续运行4.8框架。既然现有方案尚能运转，何必强修？

    回复

    1. 若性能对应用至关重要，相较4.8版本提升超过两倍。

      回复

  102. 暂缓升级。微软需要冷静一下

    回复

  103. 我们公司刚从.NET 6升级到.NET 8不久，所以…可能还要再等几年。

    回复

  104. 继续用8版，除非迁移有明显收益

    回复

    1. 迁移…基本总有好处，尤其从LTS到LTS版本。反正一年后也得迁移。

      回复

      1. 我曾将几个项目从.NET Framework 4.8迁移到.NET 8(WPF)，但未见性能或内存使用方面的提升。现在还得强制所有用户安装运行时，明明框架本就随Windows自带。而且现在所有内容都封装在dll里而非exe，单文件发布时要么根本无法运行，要么生成巨型文件。

        回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

你也许感兴趣的：