.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 发行版）

• 下载 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"
    
  
  
• 解压并放到系统目录
  
  
  
  • sudo mkdir -p /usr/share/dotnet
    
  • sudo tar -zxf dotnet-sdk.tar.gz -C /usr/share/dotnet
    
  
  
• 创建可执行链接并设置环境变量
  
  
  
  • 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、典型流水线阶段（按顺序）

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

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

感谢分享