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 csp

Answer 1

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 2

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.

Answer 3

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: