GitHub Actions中用dotnet/cli构建.NET项目需显式安装SDK、分步执行restore/build/test、指定测试路径、正确打包符号包、安全注入密钥。
GitHub Actions中用dotnet/cli构建.NET项目的关键步骤
默认的 .github/workflows/dotnet.yml 模板能跑通，但容易在 restore 或 publish 阶段失败，根本原因是没显式指定 SDK 版本和运行时目标。CI 环境不保证预装你本地用的 .NET SDK，尤其当你用的是 .NET 6+ 的隐式 usings 或 Nullable 全局设置时。
实操建议：
智能分析 Git 仓库或普通链接，自动识别内容类型并执行相应处理流程。 支持四种类型：1) OpenClaw Skills 项目（风险检测与收藏）2) 论文/文档项目（加入 dashifu——wiki 待处理队列）3) 功能项目（评估 OpenClaw 学习可行性）4) 普通网页/文章（加入 dashifu——w...
- 在 workflow 文件顶部用
actions/setup-dotnet@v4显式安装所需版本，例如dotnet-version: '8.0.x'（x表示允许补丁更新） -
dotnet restore必须在dotnet build前单独执行，且推荐加--no-cache避免 CI 缓存污染 - 若项目含多个
.csproj（如类库 + WebAPI + Tests），用dotnet build ./MySolution.sln更可靠，而非对单个项目调用build - 测试阶段务必用
dotnet test --no-build，避免重复编译；若需代码覆盖率，再额外加--collect:"XPlat Code Coverage"并配合coverlet.collector包
如何让 GitHub Actions 正确识别并运行 xUnit/NUnit 测试
常见现象是 workflow 显示 Build succeeded，但测试步骤直接跳过，或报错 No test assemblies found。这通常不是测试没写，而是 dotnet test 没找到含 [Fact] 或 [Test] 的程序集。
实操建议：
- 确保测试项目引用了对应框架包：
Microsoft.NET.Test.Sdk+xunit（或NUnit3TestAdapter） - 在 workflow 中明确指定测试项目路径，例如
dotnet test ./src/MyApp.Tests/MyApp.Tests.csproj，不要只写dotnet test - 若测试项目依赖本地 NuGet 包或 project reference，确认
dotnet restore已覆盖全部项目（可加--source参数指向 private feed） - 遇到
System.DllNotFoundException类错误，大概率是测试中用了 Windows-only API，需在 job 中设runs-on: windows-latest，或改用跨平台等价实现
发布带符号文件（.pdb）和 NuGet 包的注意事项
本地 dotnet pack 能生成 .nupkg 和 .snupkg，但 CI 中常漏掉符号包，或上传后 NuGet.org 不认。核心问题在于：符号包必须与主包完全匹配（相同 version、assembly version、hash），且需用 dotnet nuget push 单独上传。
实操建议：
- 打包时加参数：
dotnet pack --configuration Release --include-symbols --symbol-package-format snupkg - 生成的
.snupkg文件不会自动上传，必须显式调用dotnet nuget push *.snupkg -s https://api.nuget.org/v3/index.json -k ${{ secrets.NUGET_API_KEY }} - 若项目使用
Directory.Build.props控制Version，确保 CI 中未被GITHUB_RUN_NUMBER等变量意外覆盖；建议用dotnet msbuild -getProperty:Version验证实际值 - 符号服务器验证：上传后访问
https://api.nuget.org/v3/debug/symbols/YourPackage/{version}/YourPackage.pdb/{hash}/YourPackage.pdb，看是否返回 200
敏感配置（连接字符串、密钥）的安全注入方式
把 ConnectionStrings:Default 写进 appsettings.json 并提交到仓库是高危操作。GitHub Actions 提供 secrets，但不能直接映射为环境变量传给 dotnet run —— 因为 .NET 默认只从 DOTNET_* 或 ASPNETCORE_* 前缀变量读取配置。
实操建议：
- 用
env:将 secret 注入 job，再通过--environment或ASPNETCORE_ENVIRONMENT=Production触发appsettings.Production.json加载 - 更灵活的方式是运行时替换：用
sed -i "s/PLACEHOLDER/${{ secrets.DB_CONN }}/g" appsettings.json（Linux/macOS）或 PowerShell 的(Get-Content appsettings.json) -replace ... | Set-Content（Windows） - 若用 Azure Key Vault 或 AWS Secrets Manager，建议在 startup 中用
AddAzureKeyVault或AddSecretsManager，而非提前解密塞进 config 文件 - 切记：所有含 secret 的 job 必须设
if: github.event_name == 'push' && github.repository == 'owner/repo'，防止 fork PR 泄露
setup-dotnet 的版本通配符（比如写成 '7.0' 而非 '7.0.x'）导致后续 patch 更新失败，以及测试项目未显式指定路径导致 dotnet test 扫描空目录。这些细节不报错，但会让 pipeline 表面成功、实际失能。 
