Jenkins 不使用新的 MSBuild 还原目标还原 NuGet 包

Question

我们有一个 .net 完整框架 WPF 应用程序，我们已将其从.net 4.6.2 移至 4.7.1 ，并在 csproj 文件中更改为PackageReference而不是 packages.config。

在开发机器上构建似乎没问题，并且包被下载和恢复，但是当我们使用 Jenkins在我们的Windows Server 2012 构建服务器上构建时，nuget 包似乎没有正确恢复。

我们使用MSBuild v15.5和最新的“msbuild /restore”命令在构建时恢复包。 注意：使用以前调用“nuget restore”的方法确实有效，但我们现在应该能够使用msbuild /restore 。

包还原过程似乎正在查看正确的 NuGet 服务器，并且似乎在还原过程中没有出现错误（这是在 Jenkins 上编译以隔离问题的测试解决方案）：

Restore:
  Restoring packages for c:\Jenkins\workspace\Test\ConsoleApp1\ConsoleApp1.csproj...
  Committing restore...
  Generating MSBuild file c:\Jenkins\workspace\Test\ConsoleApp1\obj\ConsoleApp1.csproj.nuget.g.props.
  Generating MSBuild file c:\Jenkins\workspace\Test\ConsoleApp1\obj\ConsoleApp1.csproj.nuget.g.targets.
  Writing lock file to disk. Path: c:\Jenkins\workspace\Test\ConsoleApp1\obj\project.assets.json
  Restore completed in 577.05 ms for c:\Jenkins\workspace\Test\ConsoleApp1\ConsoleApp1.csproj.

  NuGet Config files used:
      c:\Jenkins\workspace\Test\NuGet.Config
      C:\Windows\system32\config\systemprofile\AppData\Roaming\NuGet\NuGet.Config

  Feeds used:
      http://devbuild/NuGetHost/nuget
      https://api.nuget.org/v3/index.json
Done Building Project "c:\Jenkins\workspace\Test\ConsoleApp1.sln" (Restore target(s)).

但是当 msbuild 开始编译代码时，我们会收到以下错误，看起来 NuGet 尚未下载：

CSC : error CS0006: Metadata file 'C:\Windows\system32\config\systemprofile\.nuget\packages\log4net\2.0.8\lib\net45-full\log4net.dll' 
could not be found [c:\Jenkins\workspace\Test\ConsoleApp1\ConsoleApp1.csproj]

知道为什么 nuget 包没有恢复吗？

Answer 1

经过数小时的搜索和筛选 NuGet 问题帖子并过滤掉 .net 核心噪音，我有一个修复！

根据提出的一些NuGet和 msbuild msbuild问题，在 Windows Server 2012 的本地系统帐户下使用 NuGet（或 msbuild /restore）进行还原时，NuGet 使用的文件夹不可访问，或者由于 32 位和 64 位而成为不同的文件夹正在运行的进程，因此它无法将 nuget 下载到该本地缓存文件夹。

msbuild 在编译时想要查看的这个文件夹似乎是C:\\Windows\\system32\\config\\systemprofile\\.nuget\\packages 。

我们的解决方案是使用系统范围的环境变量NUGET_PACKAGES将 NuGet 包缓存文件夹设置为不同的、可访问的文件夹，例如 C:\\NugetPackageCache 例如

NUGET_PACKAGES=C:\NugetPackageCache

您还可以通过将Build Environment->Inject environment variables to the build process->Properties Content 设置为：

NUGET_PACKAGES=C:/NugetPackageCache

根据this NuGet issue post的另一个潜在解决方案是将环境变量设置为msbuild正在寻找nugets的文件夹，即

NUGET_PACKAGES=C:\Windows\system32\config\systemprofile\.nuget\packages

注意：环境变量优先于 NuGet。 看起来他们还没有更新NuGet 文档来提及优先级。

注意：为了注入/设置环境变量，我们使用了EnvInject Jenkins 插件，如下所示：

Answer 2

我们在 .NET Framework 项目上遇到了非常相似但略有不同的情况，最近转换为 4.7.2 并使用<PackageReference>而不是packages.config ，构建在基于 Windows 的 Jenkins 服务器上，其中服务作为本地系统运行。 在我们的例子中，我们发现nuget restore根本没有查看我们的私有 MyGet 提要，因此没有从该源安装我们自己的包，这导致构建失败。 在nuget restore命令之后，它没有显示在“使用的提要”列表中。

受mips回答的启发（以及从那里链接的 NuGet 问题），我发现问题在于，尽管将C:\\Windows\\system32\\config\\systemprofile\\AppData\\Roaming\\NuGet\\NuGet.config作为配置源C:\\Windows\\system32\\config\\systemprofile\\AppData\\Roaming\\NuGet\\NuGet.config （这确实是我们配置 MyGet 提要的地方），实际上它使用的是C:\\Windows\\SysWOW64\\config\\systemprofile\\AppData\\Roaming\\NuGet\\NuGet.config 。 我能够通过将 NuGet.config 文件从 system32 位置复制到 SysWOW64 位置来解决该问题。

无需配置和注入 NUGET_PACKAGES 环境变量。

Answer 3

对我们来说，这确实是位的问题！

问题特别在于 MSBuild 实际上是在以下目录中查找 nuget 包：

C:\Windows\SysWOW64\config\systemprofile\.nuget\packages

即使日志实际上说：

C:\Windows\System32\config\systemprofile\.nuget\packages

因为被调用的 msbuild 是一个运行在 64 位平台上的 32 位进程，当它在 System32 中查找时，它实际上是在查找 SysWOW64。

这是通过文件系统重定向完成的。

我们的解决方案是简单地调用 64 位版本的 MSBuild，位于：

C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\amd64\MSBuild.exe

注意路径中的amd64 。