Jenkins not restoring NuGet packages with new MSBuild restore target

Question

We have a .net full framework WPF application that we've moved from .net 4.6.2 to 4.7.1 along with changing to PackageReference in the csproj file instead of packages.config.

Building on the development machines appears to be fine and packages are downloaded and restored, but when we build on our Windows Server 2012 build server with Jenkins , the nuget packages don't seem to be restored correctly.

We're using MSBuild v15.5 with the latest "msbuild /restore" command to restore packages at build time. Note: Using the previous way of calling "nuget restore" does work, but we should be able to use msbuild /restore now .

The package restore process appears to be looking at the correct NuGet servers and appears to go through the restore without errors (this is a test solution compiled on Jenkins to isolate the issue):

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)).

But when msbuild comes to compile the code we get the following errors which looks like the NuGet hasn't been downloaded:

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]

Any idea why the nuget packages aren't getting restored?

Answer 1

After many hours of searching and sifting through NuGet issue posts and filtering out the .net core noise, I have a fix!

According to some NuGet and msbuild msbuild issues raised, when restoring with NuGet (or msbuild /restore) under the local system account in Windows Server 2012, the folder NuGet uses isn't accessible or it's a different folder due to 32 bit vs 64 bit process that is running so it can't download nugets to that local cache folder.

This folder that msbuild wants to look in at compile time seems to be C:\\Windows\\system32\\config\\systemprofile\\.nuget\\packages .

The solve for us was to set the NuGet package cache folder using the System wide environment variable NUGET_PACKAGES to a different, accessible folder such as C:\\NugetPackageCache eg

NUGET_PACKAGES=C:\NugetPackageCache

You can also set this per Jenkins project by setting the Build Environment->Inject environment variables to the build process->Properties Content to:

NUGET_PACKAGES=C:/NugetPackageCache

Another potential solve according to this NuGet issue post is to set the environment variable to the folder that msbuild is looking for the nugets ie

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

Note: The environment variables take precedence with NuGet. It doesn't look like they've updated the NuGet docs just yet to mention the precedence .

Note: To inject/set the environment variables we are using the EnvInject Jenkins plugin which looks like this:

Answer 2

We had a very similar but slightly different situation on a .NET Framework project, recently converted both to 4.7.2 and to use <PackageReference> rather than packages.config , building on Windows-based Jenkins servers where the service runs as Local System. In our case, we found that nuget restore was simply not looking at our private MyGet feed, and consequently wasn't installing our own packages from that source, which failed the build. It was not showing in the "feeds used" list following a nuget restore command.

Inspired by mips answer here (and the NuGet issues linked to from there), I discovered that the issue was that, despite listing C:\\Windows\\system32\\config\\systemprofile\\AppData\\Roaming\\NuGet\\NuGet.config as a configuration source (which was indeed where our MyGet feed was configured), in fact it was using C:\\Windows\\SysWOW64\\config\\systemprofile\\AppData\\Roaming\\NuGet\\NuGet.config instead. I was able to solve the issue by copying the NuGet.config file from the system32 location to the SysWOW64 location.

There was no need to configure and inject a NUGET_PACKAGES environment variable.

Answer 3

For us it was indeed an issue with bitness!

The problem specifically is that MSBuild is actually looking for the nuget packages in the following directory:

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

Even though the logs actually say:

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

Because the msbuild being called is a 32-bit process running on a 64-bit platform, when it looks in System32, it's actually looking into SysWOW64.

This is done by file system redirection .

The solution for us was to simply call the 64-bit version of MSBuild, located at:

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

Notice the amd64 in the path.