问题核心 #

你遇到的情况是自定义的netstandard2.0 NuGet包foo在本地Visual Studio还原时结构正常（lib/netstandard2.0/foo.dll），但在TeamCity通过NuGet Installer还原后，DLL直接跑到包根目录，丢失了lib和框架子文件夹，导致MSBuild抛出MSB3245无法解析程序集的警告。其他官方.NET Standard包正常，说明问题大概率出在自定义包的打包过程或者TeamCity的还原配置上。

排查与解决步骤 #

1. 重新检查自定义NuGet包的打包逻辑

这是最常见的原因，很多时候自定义包打包时会不小心破坏标准结构：

• 如果是用dotnet pack命令打包：确保项目文件（.csproj）里没有自定义的<PackagePath>或者<Files>节点干扰默认输出结构。默认情况下，dotnet pack会自动将编译输出的DLL放到lib/netstandard2.0目录下。如果手动修改了打包相关的MSBuild属性，可能会导致路径错乱。
• 如果是用nuget pack+.nuspec文件打包：仔细检查.nuspec里的<files>节点，确保路径配置正确。比如正确的配置应该是：

  <files>
    <file src="bin/Release/netstandard2.0/foo.dll" target="lib/netstandard2.0" />
    <file src="bin/Release/netstandard2.0/foo.pdb" target="lib/netstandard2.0" />
  </files>
  

  不要把target写成根目录，否则打包出来的包结构就会直接把DLL放在根目录。

2. 验证TeamCity上下载的NuGet包完整性

有时候包在发布到私有/公共源时可能出现损坏，导致TeamCity下载的包结构异常：

• 在TeamCity构建代理机器上，手动从你的NuGet源下载foo.nupkg，解压后查看目录结构。如果解压后本身就没有lib/netstandard2.0文件夹，说明包发布环节出了问题，需要重新打包发布。
• 如果手动下载的包结构正常，那问题就出在TeamCity的还原过程。

3. 替换TeamCity的还原工具：用dotnet restore代替NuGet Installer

NuGet Installer（尤其是旧版本）对.NET Standard包的处理逻辑可能和dotnet restore有差异：

• 在TeamCity中新增一个构建步骤，选择“Command Line” runner，执行命令：

  dotnet restore YourSolution.sln --no-cache
  

  用dotnet restore来替代原来的NuGet Installer步骤，看看能不能正确还原foo包的结构。

4. 清理TeamCity代理的NuGet缓存

虽然你加了-NoCache参数，但有时候TeamCity代理的本地缓存可能还是有残留的损坏包：

• 登录到TeamCity构建代理机器，找到NuGet缓存目录：
  • Windows：%LOCALAPPDATA%\NuGet\Cache
  • Linux/macOS：~/.nuget/packages
• 删除其中和foo包相关的所有文件夹，然后重新触发构建。

5. 检查TeamCity工作目录的权限

极少数情况下，TeamCity代理的工作目录权限不足，导致还原时无法创建lib/netstandard2.0文件夹，只能把DLL放在根目录：

• 确保TeamCity代理服务的运行账号对构建工作目录有读写权限。
• 可以尝试在TeamCity中临时修改工作目录路径，重新构建测试。

总结 #

从你的描述来看，其他.NET Standard包还原正常，说明TeamCity的全局配置没问题，重点排查自定义包的打包正确性和TeamCity还原工具的兼容性。先从重新打包并验证包结构开始，再尝试替换还原工具，应该能解决问题。

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