YAML流水线可放子目录但需手动指定路径，推荐统一放在根目录；.NET需用UseDotNet@2显式安装匹配SDK版本；测试需coverlet.collector生成覆盖率报告；部署前须dotnet publish输出规范结构。
YAML流水线必须放在项目根目录还是可以放子目录？
必须放在项目仓库根目录下，或通过 azure-pipelines.yml 的 trigger 和 resources 显式引用其他路径；但 DevOps UI 创建流水线时默认只扫描根目录的 azure-pipelines.yml 或 .azure-pipelines/ 下的文件。若放 src/.azure-pipelines/ci.yml，需在 UI 中手动指定路径，且 checkout 步骤仍以仓库根为工作目录——这意味着所有 dotnet 命令里的路径（如 Project.csproj）要写相对根目录的路径，不是相对于 YAML 文件的位置。
- 推荐统一放在根目录：
azure-pipelines.yml - 若多项目共存，可用
paths:过滤变更范围，避免误触发 - 不要依赖“当前 YAML 所在目录”作为构建上下文——
workingDirectory需显式设为src/MyApp等子路径
如何正确配置 .NET SDK 版本和 dotnet build 步骤？
Windows 代理自带多个 .NET SDK，但版本可能滞后或不匹配项目需求；Linux/macOS 代理默认不预装 SDK，必须用 UseDotNet@2 显式安装。漏掉这步会导致 dotnet build 报错 The SDK 'Microsoft.NET.Sdk' specified could not be found 或 MSB4236: The SDK 'Microsoft.NET.Sdk.Web' was not found。
- 在
steps开头添加UseDotNet@2，指定version（如7.0.x或8.0.100），并设performMultiLevelLookup为true（尤其对 global.json 锁定版本的项目） -
dotnet build命令必须带--configuration和--no-restore（因为 restore 已由单独步骤完成，重复会拖慢流水线） - 若项目含多个 csproj，建议用解决方案文件
MySolution.sln统一构建，而非遍历每个 csproj
steps:
- task: UseDotNet@2
inputs:
version: '8.0.x'
performMultiLevelLookup: true
- script: dotnet build MySolution.sln --configuration Release --no-restore
displayName: 'Build solution'如何让 pipeline 正确执行单元测试并上传覆盖率报告？
仅运行 dotnet test 不会生成可上传的覆盖率数据；默认输出是控制台日志，Azure Pipelines 的 Code Coverage 功能需要 coverlet.collector 生成的 coverage.cobertura.xml 或 coverage.json。不配 collector 会导致 “Code coverage not reported” 警告，且无法在界面上查看图表。
- 在测试项目中添加 NuGet 包：
coverlet.collector（v6+ 兼容 .NET 6/7/8） -
dotnet test必须加参数：--collect:"XPlat Code Coverage"和--results-directory $(Build.ArtifactStagingDirectory)/testresults - 后续用
PublishCodeCoverageResults@2上传，codeCoverageTool设为cobertura，summaryFileLocation指向生成的coverage.cobertura.xml - 注意：Windows 代理上
XPlat Code Coverage依赖coverlet.collector；Linux 代理还需确保dotnet test运行时有libunwind和icu等系统依赖
发布到 Azure App Service 时，为什么 zip deploy 失败但手动上传成功？
常见原因是 AzureWebApp@1 任务默认使用 packageForLinux 或 appType 不匹配目标环境，或 publishProfile 对应的权限不足；更隐蔽的问题是：.NET 发布产物结构不符合 App Service 期望——例如未用 dotnet publish -c Release -o $(Build.ArtifactStagingDirectory)/publish 输出扁平化目录，导致 wwwroot 下没有 web.config 或 hostingstart.html 等必要文件。
- 确认 App Service 是 Windows 还是 Linux；Windows 需
appType: webApp，Linux 需appType: webAppLinux，且发布包内必须含appsettings.json和web.config（后者可通过dotnet publish自动生成） - 不要直接发布整个源码目录；务必用
dotnet publish输出到干净目录，再传给AzureWebApp@1 - 如果使用
publishProfile方式部署，检查该 profile 是否已更新（比如 TLS 设置、SCM 凭据是否过期） - 失败时先在 pipeline 中加
ls -R $(Build.ArtifactStagingDirectory)/publish查看实际发布结构
实际跑通一条 C# YAML 流水线，最难的往往不是语法，而是各环节路径、SDK 版本、产物结构之间那些隐含的耦合关系——比如 UseDotNet@2 装了 8.0，但 global.json 锁的是 7.0.400，就会静默降级；又比如 dotnet publish 输出目录没清理干净，上一次的 bin/ 残留导致部署后运行旧 DLL。这些细节不会报明显错误，但会让行为变得不可预测。
