如何在Azure DevOps Pipelines中处理关联项目构建引用问题

根本原因 #

本地Visual Studio写入sln、csproj的项目引用是基于你本地磁盘的目录结构生成的路径，而Azure Pipelines默认只会拉取当前触发构建的单仓库代码，被引用的另一个项目代码不在构建代理的工作目录里，自然无法匹配路径完成解析。

方案1：Pipeline中拉取多仓库匹配本地目录结构（改动最小，无需调整本地引用配置） #

不需要修改现有sln、csproj里的任何引用配置，只要让构建环境里两个项目的相对目录结构和你本地完全一致即可：

• 先在pipeline的资源节点声明第二个项目所在的代码库，同组织下的仓库不需要额外配置凭据，直接用内置权限即可访问：

resources:
  repositories:
  - repository: SecondRepo # 给第二个仓库自定义别名，后续步骤调用
    type: git
    name: 第二个项目名称/对应代码仓库名
    ref: main # 替换为你实际要引用的分支名，比如main、master

• 调整代码拉取步骤的存放路径，对齐本地目录结构。举个例子：你本地两个项目平级放在同一个根文件夹，目录名分别是MainProject、DependentProject，当前构建MainProject时，csproj里写的引用路径是../DependentProject/xxx.csproj，那checkout步骤配置如下：

steps:
- checkout: self # 拉取当前触发构建的仓库（也就是MainProject）
  path: s/MainProject # 存放到构建代理工作目录下的s/MainProject路径
- checkout: SecondRepo # 拉取之前声明的第二个依赖仓库
  path: s/DependentProject # 存放到s/DependentProject路径，和本地相对位置完全一致

• 后续的还原、编译步骤直接指向原有sln文件即可，路径引用会自动识别解析。
  注意：Azure Pipelines构建代理默认把拉取的代码存放在工作目录的s文件夹下，配置路径时不要写错层级；如果用Linux构建代理，路径大小写敏感，必须和csproj里记录的路径大小写完全一致。

方案2：将依赖项目打包为NuGet包（适合长期解耦维护） #

如果两个项目后续会独立迭代、独立发版，不想每次构建都拉取全量依赖代码，可以把被引用的项目打包成内部NuGet包：

• 给被依赖的项目单独配置CI流水线，每次代码合入主干时自动生成带版本号的NuGet包，推送到组织内的Azure Artifacts私有源
• 本地把原来的项目引用替换为对应NuGet包引用，提交csproj变更
• 在构建流水线的NuGet还原步骤中，添加内部Artifacts源的访问权限，构建时会自动拉取对应依赖包完成编译，不需要再维护多仓库路径。

方案3：通过Git子模块关联依赖仓库 #

如果不想配置多仓库checkout，也可以用Git子模块把依赖仓库挂到当前项目的对应路径下：

• 本地在当前项目仓库根目录执行命令添加子模块，子模块存放路径和你本地原有依赖项目的路径完全一致：git submodule add 依赖项目的Git克隆地址 本地存放路径
• 提交子模块配置文件到当前仓库
• 在Pipeline的checkout步骤开启子模块拉取配置：

steps:
- checkout: self
  submodules: true
  persistCredentials: true

构建时会自动拉取子模块代码到指定路径，完成引用解析。注意要给项目构建服务账号开放依赖仓库的读取权限，否则会拉取失败。

排查技巧 #

如果配置完还是提示找不到引用项目，直接在编译步骤前加一行命令打印目录结构：Windows代理用tree /F，Linux代理用find . -name "*.csproj"，直接看构建代理上的文件路径和csproj里写的是不是完全匹配，90%的路径问题都能通过这个方式定位。
另外如果csproj里写的是本地绝对路径，必须改成相对路径，绝对路径不可能在不同构建代理环境下匹配，本地开发也建议全部用相对路径配置项目引用。

内容的提问来源于stack exchange，提问作者Sascha Manns