这种同仓库跨解决方案引用的构建坑我踩过好几次，核心原因基本都是构建输出路径不匹配或者构建任务的依赖/配置没对齐，给你几个具体的排查和解决方向：

1. 对齐两个解决方案的构建配置与输出路径 #

首先得确保解决方案B的输出能被A找到：

• 打开B里被引用的项目属性，转到「生成」标签，记下它的「输出路径」（比如bin\$(Configuration)\）。
• 再看A里的引用设置：如果是项目引用，确认「复制本地」设为True（项目引用一般会自动同步，但偶尔配置异常会失效）。
• 重中之重：VSTS构建时，两个解决方案必须用完全相同的配置（Debug/Release）！如果B用Release构建输出到bin\Release\，而A用Debug构建去bin\Debug\找，肯定会找不到DLL。

2. 统一构建输出到公共目录 #

别让两个解决方案各自输出到自己的bin目录，指定一个公共输出目录，让A能直接拿到B的产物：

• 给解决方案B的MSBuild构建任务添加参数：/p:OutputPath=$(Build.ArtifactStagingDirectory)\bin
• 解决方案A的MSBuild任务也加上同样的参数，这样两个方案的输出都集中到同一个目录，A就能顺利找到B的DLL了。

3. 确保构建任务严格按顺序执行 #

虽然你说先构建B再构建A，但要确认VSTS管道里的任务是真的按顺序跑：

• 在构建管道中，给A的构建任务设置依赖：在任务的「控制选项」里，把「运行此任务」设为「只有当所有先前任务成功时」。
• 别用“一次性构建多个解决方案”的方式，分开成两个独立的MSBuild任务，先跑B的构建，再跑A的，避免MSBuild并行构建导致的依赖混乱。

4. 检查解决方案文件的引用路径 #

如果A是通过项目引用关联B的项目，要确认仓库里的.sln文件路径是对的：

• 打开A的.sln文件，找类似这样的行：

  Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "B.Project", "..\B\B.Project\B.Project.csproj", "{GUID}"
  

  确保相对路径和仓库的目录结构匹配，本地能跑但CI环境跑不通，大概率是路径问题。

5. 清理构建缓存 #

有时候VSTS代理的旧缓存会搞事情，导致引用路径混乱：

• 在构建管道开头加一个「清理本地工作区」的任务，或者给MSBuild任务加/t:Clean,Build参数，确保每次构建都是干净的环境。

内容的提问来源于stack exchange，提问作者Netanel Stern