Nuke 构建脚本需通过 nuke :setup 生成标准 Build.cs（同级目录、含 SDK 声明），禁用静态字段初始化 HttpClient，环境变量用 Environment.GetEnvironmentVariable，路径用 / 运算符，测试需确认程序集路径，Azure DevOps 部署要设绝对输出路径并显式声明 DependsOn。
如何在 C# 项目里初始化 Nuke 构建脚本
直接用 dotnet tool install --global Nuke.GlobalTool 装完就能跑，但别急着写逻辑——Nuke 会自动生成一整套带 Git 忽略规则、CI 配置占位符和基础构建目标的骨架，关键在于执行 nuke :setup 后要立刻检查生成的 Build.cs 是否被正确识别为 MSBuild 项目（即有没有 <project sdk="Microsoft.NET.Sdk"></project>）。常见错误是手动新建空文件或复制旧模板，结果 nuke 命令报 Could not find build project，本质是没让 MSBuild 加载它。
- 必须确保
Build.cs文件名固定，且和解决方案同级（或通过--root显式指定） - 生成后立即运行
nuke --help，看到列出的 target 才算成功；如果只显示“no targets found”，八成是Build.cs没被 SDK 引用 - 不要把
Build.cs放进任何<projectreference></projectreference>，它不是普通类库，Nuke 运行时会单独编译它
为什么 Build.cs 里不能直接 new HttpClient() 或读取环境变量
Nuke 的构建脚本在执行时默认以“隔离模式”运行：所有静态构造函数、全局变量初始化、static 字段赋值都发生在构建上下文之外，而真正执行 target 逻辑时，Nuke 会重新加载并实例化 Build 类。这意味着你在 Build 类顶部写的 private static readonly var client = new HttpClient(); 实际上会在每个 target 执行前被重复创建，且无法复用连接池——更糟的是，某些 CI 环境（如 GitHub Actions）会因 DNS 缓存或证书验证失败导致首次请求超时。
- 改用
HttpClient.DefaultRequestHeaders+HttpClientFactory（需引用Microsoft.Extensions.Http） - 环境变量务必用
Environment.GetEnvironmentVariable("XXX")，别依赖Configuration或IOptions，Nuke 不加载 ASP.NET Core 配置系统 - 路径拼接一律用
RootDirectory / "src"（/是 Nuke 重载的路径运算符），别用Path.Combine，否则 Windows/Linux 行为不一致
RunTest target 报错 “No test assemblies found” 怎么定位
这不是 Nuke 本身的问题，而是 DotNetTest 工具找不到匹配的 *.Tests.dll。Nuke 默认只扫描 **/bin/**/*Tests.dll，但如果你的测试项目用了 <ispackable>false</ispackable> 或 <copytooutputdirectory>PreserveNewest</copytooutputdirectory>，输出目录可能不在默认路径下。
- 先手动运行
dotnet test --list-tests --configuration Release确认测试程序集是否存在、路径是否可访问 - 在
RunTesttarget 里显式指定SetProjectFile或SetProcessArgumentConfigurator，比如：.SetProjectFile(Solution.MyAppTests) - 注意
DotNetTest默认跳过net48项目，如果测试项目是 .NET Framework，得换用VSTest工具，并传/Framework:Framework48
部署到 Azure DevOps 时 Publish target 卡住不动
表面看是 Nuke 没响应，实际多是 DotNetPublish 在等待符号服务器认证，或者输出路径被权限锁死。Azure Pipelines 的托管代理默认禁用交互式凭据弹窗，而某些 NuGet 源（尤其私有源）配置了 <add key="enableInteractive" value="true"></add>，导致 publish 进程挂起。
- 加
.SetNoRestore(true)避免重复 restore（CI 中通常已提前做过了） - 发布路径强制用绝对路径：
.SetOutputDirectory(RootDirectory / "artifacts" / "publish")，相对路径在不同 agent 上容易解析错 - 若涉及签名或符号上传，改用
DotNetPack+ 显式dotnet nuget push分步执行，别塞进一个 publish 流程里
最常被忽略的一点：Nuke 的 TargetAttribute 顺序不等于执行顺序，依赖关系必须靠 DependsOn 显式声明，光靠方法定义顺序没用。比如 Compile 和 Test 都标了 [Target]，但没写 Test.DependsOn(Compile)，CI 就可能并行跑甚至反序执行。
