.NET 10 社区SDK（Loongarch 和 RISC-V）

在微软发布了.NET 10(X86/X64/ARM)版本的同时，社区也同时基于Github Action流水线发布了.NET 10 的社区SDK（Loongarch 和 RISC-V），这篇文章重点就是介绍.NET 10 社区SDK（Loongarch 和 RISC-V）。

一、Loongarch（loongarch64 / Loongson）上 .NET 10

概览

• 发布：v10.0.100-loongarch64（tag）
• 发布者（自动化）：github-actions[bot]
• 发布时间（UTC）：2025-11-14T13:21:44Z
• 类型：prerelease（预发布）
• 目标分支：build
• Release 页面正文为空（未附带额外说明），但包含一组构建产物（tar.gz 与 NuGet 包）用于 loongarch64 平台。
• 仓库：https://github.com/loongson/dotnet

重点说明

• 支持平台：loongarch64（即 Loongson CPU 架构的 Linux）。
• 覆盖范围：SDK、运行时（dotnet runtime）、ASP.NET Core 运行时、NativeAOT 运行时、Crossgen2、ILCompiler、Host 包和若干 native/系统库的 NuGet 包与源构建产物。
• 这是“预发布”构建，说明可能是针对 Loongson 社区或内部构建发布来验证在 loongarch64 上的兼容性和功能；在生产环境使用前应充分测试。

如何下载（示例）

• 直接使用 Release 下载 URL（示例）：
  • https://github.com/loongson/dotnet/releases/download/v10.0.100-loongarch64/dotnet-sdk-10.0.100-linux-loongarch64.tar.gz
• 或在 Release 页面通过“Assets”手动下载相应文件。

快速安装（常规 tarball 安装步骤，适用于大多数 Linux 发行版）

1. 下载 tarball 到主机
   • curl -L -o dotnet-sdk.tar.gz "https://github.com/loongson/dotnet/releases/download/v10.0.100-loongarch64/dotnet-sdk-10.0.100-linux-loongarch64.tar.gz"
2. 解压并放到系统目录
   • sudo mkdir -p /usr/share/dotnet
   • sudo tar -zxf dotnet-sdk.tar.gz -C /usr/share/dotnet
3. 创建可执行链接并设置环境变量
   • sudo ln -s /usr/share/dotnet/dotnet /usr/bin/dotnet
   • export DOTNET_ROOT=/usr/share/dotnet
   • export PATH=$PATH:/usr/share/dotnet （注：上面是常用做法，视你的发行版和安全策略调整。某些发行版或包管理器可能需要不同的步骤。）

测试建议

• 验证 dotnet 可执行：
  • dotnet --info
• 编译并运行一个简单的 Console 应用：
  • dotnet new console -o testapp && cd testapp && dotnet run
• 针对 ASP.NET：使用 aspnetcore-runtime 的示例应用部署与访问测试。
• 测试 NativeAOT、Crossgen2、以及涉及 System.IO.Ports 的功能（若你需要串口支持）。

风险与注意事项

• 由于是预发布版本，可能包含未解决的问题或性能/互操作性差异，建议在非生产环境先进行完整回归测试。
• 若你依赖第三方原生库或特定 Linux 发行版的 ABI，测试兼容性很重要。

二、RISC-V .NET 10

概览

• 发布标题 / 标签：10.0.100-rtm.25561.199 (tag: 10.0.100-rtm.25561.199)
• 发布时间：2025-11-12T00:45:00Z
• 发布类型：预发布 (prerelease: true)
• 目标分支：main
• 作者：github-actions[bot]（自动化构建/上传）
• 仓库：https://github.com/filipnavara/dotnet-riscv
• 附件（资产）：dotnet-sdk-10.0.100-rtm.25561.199-linux-riscv64.tar.gz
  • 说明：这是为 Linux on RISC‑V (riscv64) 提供的 .NET 10 SDK 二进制包

简要解释

• 这是一个面向 RISC‑V（riscv64）的 .NET 10 SDK 的 RTM 构建包，发布为预发行版，表明它是供测试/早期试用的构建而非正式稳定发布（没有随附发布说明或变更日志）。资产名称显示这是一个 Linux 平台的 tar.gz 安装包。

三、基于GitHub Actions 流水线发布 .NET SDK

.NET 10 社区SDK（Loongarch 和 RISC-V）能够快速的同步进行构建发布，主要是从.NET 9 开始实现了基于同一套代码基线构建.NET SDK的基础设施，下面就基于 GitHub Actions 流水线发布 .NET SDK的原理与典型过程拆成几个部分来讲清楚：总体流程、关键步骤、所需凭证/基础设施、常见实现细节（包含示例 workflow 片段）、以及注意事项与最佳实践。最后我会列出如果你想要我继续可以帮你做的后续工作。

3.1、总体概念（为什么要用 CI/CD 发布 SDK）

• 目标：把源码编译成跨平台的 SDK 二进制/安装包（zip/tar、pkg/dmg、msi/deb/rpm 等），做签名、生成校验和、上传到发布位置（GitHub Release、Azure Blob/Storage、官方 feed 或镜像站），并更新安装脚本/渠道（例如 dotnet-install 脚本或网站上的版本清单）。
• GitHub Actions 作为自动化引擎：触发（tag/release、手动/dispatch、定时）→ 构建 → 测试 → 打包/签名 → 发布 → 后置更新/通知。
• 区分 CI（PR 验证、快速构建）与 Release 流水线（正式标签触发、全量测试与签名、需要敏感凭据）。

3.2、典型流水线阶段（按顺序）

1. 触发（Trigger）
   • 常见触发：push tag（例如 v10.0.0-preview1 或 v10.0.0），release created、workflow_dispatch（手动触发）、或从发布协调器触发的 API 调用。
   • Release 流程通常只在经过人工审核或特殊权限后允许写入敏感凭据/生产证书的 runner 上运行。
2. 环境准备 / Checkout
   • 使用 actions/checkout 拉代码。
   • 设置必要的运行环境（选择 runner：ubuntu-latest、windows-latest、macos-latest 或自托管 runner；很多 SDK 发布依赖自托管 Windows/macOS 机器来完成代码签名或生成 platform-specific installer）。
   • 拉取子模块或相关 repo（例如 runtime、libraries、installer 模块等）。
3. 引导/依赖安装
   • 运行构建脚本的引导（对 .NET 常见是 repo 镶嵌的 build.ps1/build.sh 或使用 repo-toolset）。
   • 如果是交叉构建，可能需要先安装早期版本的 dotnet 来做 bootstrapping（使用 dotnet-install 脚本或 actions/setup-dotnet）。
4. 编译（Build）
   • 多 OS/arch 的矩阵构建（x64/arm64；Windows/Linux/macOS）。
   • 构建会生成 runtime、host、sdk 二进制，可能会调用 msbuild/dotnet build/clang/gcc 等。
   • 构建输出分目录（sdk、shared runtime、hostfxr、hostpolicy、packs 等）。
5. 测试（Tests）
   • 单元测试、集成测试、回归测试。
   • 对 Release 通常会更多：较长时间的 E2E、兼容性测试、安装与卸载测试、sample app 运行测试。
   • 有时会在不同平台上做“smoke tests”来确保包可以实际执行。
6. 打包（Package）
   • 生成 SDK zip/tar、NuGet 包、Windows MSI、macOS pkg 或 dmg、Linux deb/rpm。
   • 生成校验和（sha256/sha512），并生成版本元数据（manifest/json），用于后续下载/安装脚本解析。
7. 签名（Code/Artifact Signing）
   • 对可执行文件、安装包进行代码签名（Windows 使用 SignTool + EV 证书、macOS 使用 codesign + notarize、包使用 GPG 签名或微软的签名流程）。
   • 这一步通常需要访问机密（证书、私钥、时间戳服务），生产环境多用自托管 runner 或安全的签名服务。
8. 发布（Publish / Upload）
   • GitHub Releases（创建 release 并上传 asset）
   • Azure Blob Storage / CDN（供下载安装）
   • 官方 feed（如 NuGet、internal feeds）
   • 镜像站、内部渠道
   • 上传构建产物到发布存储：
   • 更新安装脚本或版本清单（例如更新 dotnet-install 的 JSON 或网站的下载页面），并将变更推送到相应 repo（可能需要另一个工作流或 API 调用）。
9. 后置工作（Post-release）
   • 通知（Slack 邮件）/更新文档/创建 release notes。
   • CDN 缓存失效、镜像同步。
   • 监控发布后的用户反馈 / 自动化探测（如 health checks、telemetry 验证）。

3.3、关键基础设施与凭据

• 自托管 runners：用于访问私有签名证书或生成 macOS notarize（Apple 只在 macOS 上能做）。
• Secrets（GitHub Secrets / Azure Key Vault / HashiCorp Vault）：
  • 代码签名证书（.pfx 或硬件密钥访问的凭据）。
  • Apple Developer 密钥、notary credentials。
  • GPG 私钥（如果用 GPG 签名）。
  • Azure Storage connection string / SAS token / Azure AD client secret（用于上传到 blob）。
  • NuGet API keys（发布包）。
  • GitHub token（用于创建 release、上传 release assets，注意权限限定）。
• 时间戳服务 / Timestamp URLs：在代码签名时保持长期有效性。
• Artifact 存储与 CDN：用于高速下载并支持回滚/版本管理。

3.4、常见实现细节与自动化点

• 构建并行化：用矩阵 jobs 构建多个 OS/arch，或把某些构建拆成并行 job 来加速。
• 依赖缓存：actions/cache 缓存 NuGet 包和构建中间产物，减少重复耗时工作。
• 可复现/可审计：
  • 生成 SBOM（软件物料清单）。
  • 生成构建元数据（构建ID、commit、时间戳），并写入 release notes/manifest。
  • SLSA/Provenance：签署构建证明（使用 sigstore 等）以保证来源可验证。
• Release gating 与手动审批：
  • 对 release job 使用 environment protection rules（需要手动批准或审核）。
  • 对访问敏感 secrets 的 job 限制为特定环境或 runner。
• 打包的跨平台差异：
  • Windows：MSI/ZIP/EXE，需 SignTool，可能还要生成 installer bootstrapper。
  • macOS：pkg/dmg, codesign + notarize（需要 Apple Notary）。
  • Linux：deb/rpm，不签名二进制但可以签署包（RPM签名、GPG）并上传到 apt/yum repo。
• 发布渠道管理：
  • 维护“preview”和“stable”频道：通过不同 tag/manifest 决定 dotnet-install 脚本哪个版本被默认下载安装。
  • 有时候会分阶段发布（先到 Canary/staging/insider，再到 public stable）。