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位不同而是一个不同的文件夹正在运行的进程,因此无法将nugets下载到该本地缓存文件夹.

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

解决我们的问题是使用系统范围的环境变量NUGET_PACKAGES将NuGet包缓存文件夹设置为另一个可访问的文件夹,例如C:\ NugetPackageCache,例如:

NUGET_PACKAGES=C:\NugetPackageCache

您还可以通过将Build Environment-> Inject环境变量设置为构建过程 - >属性内容来为每个Jenkins项目设置此项:

NUGET_PACKAGES=C:/NugetPackageCache

根据这个NuGet问题的另一个潜在的解决方案是将环境变量设置为msbuild正在寻找nugets的文件夹,即

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

注意:环境变量优先于NuGet.看起来他们还没有更新NuGet文档,只是提到优先级.

注意:要注入/设置环境变量,我们使用EnvInject Jenkins插件,如下所示:

Answer 2

对于我们来说，这确实是一个位数问题！

具体问题是 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 。

Answer 3

我们在 .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配置源（这确实是我们配置 MyGet 提要的地方），但实际上它正在使用C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming\NuGet\NuGet.config。我能够通过将 NuGet.config 文件从 system32 位置复制到 SysWOW64 位置来解决该问题。

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