.NET 11 RC1 可用于生产：升级前需要验证的五个变化

2026-09-15 11 预计阅读时间: 1 分钟
来源: infoq.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：8 分钟

.NET 11 RC1 是这一发布周期的首个候选版本。与普通预览版不同，它附带 Go-Live 支持许可，意味着符合支持条件的团队可以开始将其用于生产环境。不过，“允许上线”并不等于“升级没有风险”：运行时、编译器、测试工具链和移动工作负载都发生了变化，正式切换前仍需要完整验证。

这次发布包含几项直接影响工程实践的更新：C# 15 和 F# 11 成为默认语言版本，dotnet test 扩展到移动端与桌面端目标，SignalR 身份验证刷新 API 定型，同时 .NET MAUI 的 Android 构建速度得到改善。

默认语言版本改变了编译基线

使用 .NET 11 SDK 构建项目时，C# 15 和 F# 11 将成为各自语言的默认版本。新建项目可以直接采用新的语言能力；已有项目则要留意编译器行为、分析器以及源码生成器的兼容性。

最稳妥的做法是把 SDK 和语言版本显式写入仓库。安装 .NET 11 RC1 SDK 后，可以这样创建一个最小项目：

mkdir net11-rc1-demo
cd net11-rc1-demo

dotnet new globaljson --sdk-version 11.0.100-rc.1 --roll-forward latestPatch
dotnet new console --framework net11.0

dotnet --info
dotnet restore
dotnet run

运行前需要把 11.0.100-rc.1 改成机器上实际安装的 RC1 SDK 完整版本，可通过 dotnet --list-sdks 查询。提交 global.json 后，本地开发机和 CI 会使用一致的 SDK 选择规则。

如果团队希望先升级运行时和 SDK，但暂时维持旧语言基线，可以在项目文件中锁定语言版本：

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net11.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <LangVersion>14.0</LangVersion>
  </PropertyGroup>
</Project>

反过来，如果决定跟随 .NET 11 的默认值，通常可以删除 LangVersion。不要在共享代码库里随意使用 preview，否则后续 SDK 更新可能悄悄改变可用语法和编译结果。

测试入口开始覆盖更多应用形态

dotnet test 扩展到移动端和桌面端目标，价值不只是少记几条命令。它让测试入口更统一，也更容易复用 CI 的过滤、日志和结果归档逻辑。

可以先用普通测试项目验证 RC1 工具链：

dotnet new xunit -n Net11SmokeTests --framework net11.0
cd Net11SmokeTests

dotnet test \
  --configuration Release \
  --logger "trx;LogFileName=net11-rc1.trx" \
  --results-directory ./TestResults

对于移动端或桌面端测试项目，可以沿用同一入口，并按项目实际声明的目标框架执行：

# 将目标框架替换为项目文件中真实存在的 TFM。
dotnet test tests/MyApp.DeviceTests/MyApp.DeviceTests.csproj \
  --framework net11.0-android \
  --configuration Release

这类测试仍然依赖对应 workload、SDK、模拟器或设备环境。命令统一并不会消除平台依赖，因此 CI 中应把纯单元测试与设备测试拆成不同任务，并分别设置超时、重试和测试结果收集策略。

SignalR 与 MAUI 的变化应如何落地

SignalR 身份验证刷新 API 在 RC1 中定型，这对长连接应用尤其重要。令牌轮换、会话续期和权限变化不应再只依赖断线重连来生效。升级时应重点覆盖三类场景：令牌正常刷新、刷新失败，以及用户权限在连接存续期间发生变化。

由于摘要没有给出最终 API 的具体签名，实际接入时应以 RC1 SDK 文档和引用程序集为准，不宜继续依赖预览阶段的示例代码。可以先检查项目中的 SignalR 包是否与目标框架一致：

dotnet list src/MyRealtimeApp/MyRealtimeApp.csproj package
dotnet list src/MyRealtimeApp/MyRealtimeApp.csproj package --outdated

.NET MAUI 方面，本次更新改善了 Android 构建时间。团队应使用自己的应用进行冷构建和增量构建测量，而不是只观察一次本地编译：

dotnet clean src/MyMauiApp/MyMauiApp.csproj -f net11.0-android

time dotnet build src/MyMauiApp/MyMauiApp.csproj \
  -f net11.0-android \
  -c Release

time dotnet build src/MyMauiApp/MyMauiApp.csproj \
  -f net11.0-android \
  -c Release

第一轮可作为冷构建近似值，第二轮用于观察增量构建。为了让对比有效，应固定 SDK 版本、Java 环境、Android workload、构建配置和 CI 机器规格。

Go-Live 不等于零风险

Go-Live 支持许可让 RC1 具备生产采用的现实意义，但它依然是候选版本。正式版发布前仍可能出现修复，第三方库、分析器、IDE 扩展和监控探针也未必同步完成验证。

建议采用分阶段策略：

  1. 用 global.json 固定 RC1 SDK，避免开发机和 CI 自动漂移。
  2. 先升级内部工具、测试环境或低风险服务，观察编译告警、性能和运行时异常。
  3. 对 SignalR 应用执行令牌刷新、连接恢复和权限变更测试。
  4. 对 MAUI 应用分别记录 Android 冷构建、增量构建和安装测试耗时。
  5. 保留上一稳定版 SDK 和部署产物，确保可以快速回滚。
  6. 检查云平台、容器基础镜像和 APM 探针是否明确支持 .NET 11 RC1。

.NET 11 RC1 已经把本周期的关键能力推到接近最终状态。适合现在采用它的团队，通常具备完善的自动化测试、可回滚部署和 SDK 版本治理；如果项目严重依赖尚未声明兼容的第三方组件，等待正式版通常更稳妥。

# Go # InfoQ # 全栈 # 后端

相关推荐