C#怎么创建CI CD自动部署_C# GitHub Actions持续集成教程【实战】-C#.Net教程-PHP中文网

C#项目CI/CD需显式安装.NET SDK并正确配置：指定runs-on、用actions/setup-dotnet@v4匹配targetframework、必含actions/checkout@v4；测试失败多因缺失Test.Sdk或跨平台API；发布须用Secrets管理密钥，NuGet还原失败常因私有源未配置。

c#怎么创建ci cd自动部署_c# github actions持续集成教程【实战】

GitHub Actions 是 C# 项目实现 CI/CD 最轻量、最直接的方案，不需要自建 Jenkins 服务器，也不依赖 Azure DevOps 订阅。只要你有 GitHub 仓库，就能跑起完整的构建、测试、发布流程。

怎么写 `.github/workflows/ci.yml` 才能真正编译 C# 项目

很多初学者直接套用 Node.js 模板，结果 dotnet build 报错“command not found”——因为默认 Ubuntu runner 不自动装 .NET SDK。

必须显式指定 runs-on: ubuntu-latest 或 windows-latest，并用 actions/setup-dotnet@v4 安装对应 SDK 版本
dotnet-version 要和项目 global.json 或 .csproj 中的匹配（比如 net8.0 就得配 8.x）
别漏掉 actions/checkout@v4，否则工作流根本拉不到代码

最小可用示例：

name: C# CI
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.x'
      - name: Build
        run: dotnet build --configuration Release

`dotnet test` 运行失败常见原因

不是所有测试项目都能直接 dotnet test 成功。常见卡点：

测试项目未引用 Microsoft.NET.Test.Sdk —— 编译会过，但 dotnet test 找不到适配器，报 No test is available
使用了 xunit 但没装 xunit.runner.visualstudio 或对应 CLI runner 包
测试里用了 Windows-only API（如 Registry），却在 ubuntu-latest 上跑，直接抛 PlatformNotSupportedException

建议：CI 中统一用 dotnet test --no-build --verbosity normal，加 --verbosity 能快速定位是找不到测试还是运行崩溃。

openclaw-github-config-impact

OpenClaw 技能 — 给定一个 GitHub 仓库 URL，自动解析出 owner/repo 名称，发现其中的 YAML/properties 配置文件及其配对的中文字段说明；在 `workspace/{repo}/` 目录下按同步日期（格式为 `YYYY-MM-DD`）创建时间戳子目录；写入 `.openclaw-config-state.json` 状态文件。每次用户提问前，先比对远程仓库当前 ref（如 `main` 或 `master`）的最新提交 SHA 与本地状态文件中记录的 SHA：

下载

怎么把 `dotnet publish` 输出部署到云环境

发布本身很简单：dotnet publish -c Release -o ./publish，但“部署到哪”和“怎么鉴权”才是关键。

部署目标决定你用什么 Action：推 Docker 镜像用 docker/login-action，发到 Azure Web App 用 azure/webapps-deploy@v2，微信云托管则要用官方 CLI 工具 + WXCLOUD_APPID/WXCLOUD_CLI_SECRET 密钥
密钥绝不能硬编码进 YAML，必须存在 GitHub Secrets 里，然后用 ${{ secrets.WXCLOUD_APPID }} 引用
Windows 环境下发布 ASP.NET Core 站点时，注意 --self-contained false（依赖系统运行时）比 true 更省空间、启动更快

为什么本地能跑通，CI 却提示 NuGet 包还原失败

典型错误信息：NU1101: Unable to find package xxx 或 NU1603: xxx depends on yyy (>= 1.0.0) but yyy was not found.

检查 .csproj 是否用了私有 NuGet 源（比如公司内网 feed），CI 默认只走 nuget.org
需要在 workflow 里加一步 nuget/authenticate 或手动写 NuGet.Config 并用 actions/upload-artifact 传入
更稳妥的做法：用 dotnet restore --configfile NuGet.Config 显式指定配置文件路径

最常被忽略的一点：C# 项目若含多个 .sln 文件，dotnet restore 必须指定具体 sln 路径，否则可能只还原了部分项目依赖。