CruiseControl.NET CI服务器执行dotnet build失败，无法解析NuGet包

这种情况我之前处理过类似案例，核心原因基本都是管理员身份运行时的NuGet运行环境和普通用户不一致，以下是具体的排查方向和解决办法：

1. 检查NuGet源配置的差异 #

普通用户的NuGet配置文件存放在 %USERPROFILE%\.nuget\NuGet\NuGet.Config，而管理员身份运行时，会优先加载管理员用户目录（C:\Users\Administrator）下的配置，或者系统级配置（C:\ProgramData\NuGet\Config）。很可能管理员环境里缺少了必要的NuGet源（比如官方的nuget.org），或者源被禁用。

排查与解决： #

• 分别在普通cmd和管理员cmd里执行以下命令，对比输出的源列表：

  dotnet nuget list source
  

• 如果管理员环境中没有nuget.org源，执行命令添加：

  dotnet nuget add source https://api.nuget.org/v3/index.json -n nuget.org
  

• 或者直接将普通用户的NuGet.Config文件复制到管理员用户的.nuget\NuGet目录下。

2. 验证管理员身份的网络访问权限 #

虽然是管理员，但服务器的网络策略可能限制了管理员进程访问外部网络（比如nuget.org），而普通用户进程不受限制。常见的情况包括防火墙规则、代理配置差异。

排查与解决： #

• 在管理员cmd里执行以下命令，测试能否正常访问NuGet官方源：

  curl https://api.nuget.org/v3/index.json
  

  如果无法返回内容，检查服务器防火墙是否允许管理员进程访问该地址，或者对比普通用户和管理员的代理配置：

  netsh winhttp show proxy
  

  确保管理员身份的代理设置和普通用户一致。

3. 检查CI任务的工作目录与环境变量 #

CruiseControl.NET运行任务时的工作目录、环境变量可能和你手动执行cmd时不一致，比如NUGET_PACKAGES环境变量指向了一个没有读写权限的目录，导致无法缓存或下载包。

排查与解决： #

• 在CI任务中添加前置步骤，输出当前工作目录和NuGet相关环境变量：

  echo 当前工作目录：%CD%
  set NUGET
  

  对比手动执行时的输出，确认差异。
• 可以在dotnet build命令中强制指定包缓存目录，确保有读写权限：

  dotnet build foo.sln --packages C:\Temp\NuGetPackages
  

4. 清理管理员身份下的NuGet缓存 #

管理员身份使用的NuGet缓存可能损坏，导致无法正常解析包，而普通用户的缓存是正常的。

解决办法： #

在管理员cmd里执行以下命令清理所有NuGet缓存，然后重新运行build：

dotnet nuget locals all --clear

内容的提问来源于stack exchange，提问作者Anders Lindén