C# Azure DevOps流水线方法 C#如何为.NET项目创建YAML流水线

来源：这里教程网时间：2026-02-21 17:40:48 作者：

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 版本、产物结构之间那些隐含的耦合关系——比如