VSTS中Asp.Net Core引用共享类库构建失败问题求助

我之前也碰到过类似本地正常但CI构建翻车的情况，结合你的描述，大概率是路径映射或者源代码拉取不完整导致的，给你几个具体的排查和解决方向：

1. 核对项目引用的相对路径是否准确 #

打开你的Asp.net Core项目的.csproj文件，找到共享类库的引用节点，比如：

<ProjectReference Include="..\SharedLibrary\KapseoPlus.Models\KapseoPlus.Service\KapseoPlus.Service.csproj" />

本地能编译说明这个相对路径在你本地是对的，但VSTS构建代理上的文件结构可能和你本地不一致。你可以去构建日志的Get Sources步骤里，查看拉取后的目录结构，对比本地的文件夹层级，确认共享类库的实际位置是不是和你引用的路径匹配。

2. 确认VSTS已拉取完整的共享类库文件 #

有时候TFS的工作区映射或者VSTS构建的Get Sources配置会出问题，导致共享类库没被同步到构建代理的工作目录：

• 打开你的VSTS构建定义，进入Get Sources选项卡，检查「工作区」的映射规则，确保共享类库所在的文件夹已经被正确映射到$(Build.SourcesDirectory)下的对应路径。
• 在失败的构建日志里，查看Get Sources步骤的输出，确认D:\a\3\s\SharedLibrary\KapseoPlus.Models\KapseoPlus.Service\这个路径下是否真的存在KapseoPlus.Service.csproj文件，如果没有，说明源代码没拉全，得调整工作区映射。

3. 检查构建依赖的配置逻辑 #

本地编译时Visual Studio会自动处理项目依赖，但VSTS构建可能需要明确配置：

• 确认你的Asp.net Core项目添加的是项目引用，不是直接引用DLL的文件引用。
• 如果用Visual Studio Build步骤，确保选择的是包含所有项目的解决方案文件，而不是单独的Asp.net Core项目，这样构建会自动按依赖顺序编译。
• 如果用Dotnet Build步骤，要么先单独构建共享类库，要么直接指定解决方案文件来构建，不要只编译单个Asp.net Core项目。

4. 验证构建代理的工作目录设置 #

VSTS默认工作目录是D:\a\{BuildId}\s，如果你的解决方案结构复杂，可能需要调整构建步骤的工作目录：

• 在Visual Studio Build或Dotnet Build步骤中，检查「工作目录」是否指向你的解决方案所在的文件夹，这样相对路径才能正确解析。

5. 清理缓存试试（玄学但有用） #

有时候缓存会导致各种奇怪的问题：

• 本地清理Visual Studio的缓存（删除项目根目录的.vs文件夹，清理NuGet缓存）。
• 在VSTS构建定义的Get Sources选项卡的「高级」设置里，开启「清理工作区」，让每次构建都拉取干净的源代码。

如果这些步骤都试过还是不行，可以把构建失败日志里和路径相关的完整内容贴出来，能更精准定位问题。

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