Make Jenkins aware of custom NuGet Package Source

Question

I've got a little issue regarding Jenkins and NuGet package restore.

What I'm trying to do is build solutions on jenkins (which works perfectly fine). I have enabled package restore for the solution, which generates the .nuget-folder containing NuGet.exe, NuGet.Config and NuGet.targets.

On Jenkins, I am pulblishing some projects as NuGet-packages in a private package source on our server. I am using those packages in other projects, which should be build on jenkins themselves.

VS knows about the private package source, it's configured in the global NuGet.Config-file (the one under AppData) and it is not disabled (by default).

Now, when I try to build a solution which needs a package from the private package source, the build fails, because jenkins doesn't know about it, and is therefore commiting an empty -source-parameter when restoring packages which is not beeing replaced as jenkins doesn't know about the custom source.

What I've tried so far

1. I already know that adding the private source to the solutions NuGet.Config- or NuGet.Targets-file's Package-Source would solve the problem, but that would mean, i would have to do so for every solution I want to build using Jenkins.

2. I have also played around a bit with the config-files in AppData and ProgramData by adding the source in to the package-source tags in the files and even making it the active-source, but that didn't help either

3. of cource, commiting the packages would be a workaround, but thats not the desired outcome, as we'd like to ignore the packages in scm.

Basically, i'd like to know if there is a way to make Jenkins constantly aware of the private package source, or to manipulate the NuGet-installations on the developers maschines, so that they generate a NuGet.targets-file which contains the private package-source. An other possible fix would be a parameter for msbuild, which I'm not aware of.

Any help is greatly appreciated!

Answer 1

To sum up (and extend) my comments:

Nuget package restore via msbuild is deprecated in current versions of Nuget (2.7 and higher)

We use a batch step in Jenkins

nuget.exe restore SOLUTIONTOBUILD.sln -source http://nugetserver...

and avoid thereby the problem that the Jenkins service runs in a different account and searches for the .config in a different place.

On the developer machines, the packages are restored by the Nuget-VS-Addin (and not by msbuild), so don't forget to undo the changes that the old Nuget-VS-Addin may have applied to your project-files.

More Information can be found in the Nuget-Docs

Answer 2

Another solution to this problem is to add your custom NuGet.config and executable to a directory on the Jenkins server, and add a build step to run nuget using the custom config.

C:\nuget\nuget.exe update "%WORKSPACE%\Project.sln" -ConfigFile C:\nuget\NuGet.config

A NuGet.config adding a custom package source would look something like this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageRestore>
    <add key="enabled" value="True" />
    <add key="automatic" value="True" />
  </packageRestore>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
    <add key="My Custom Package Source" value="http://localhost/guestAuth/app/nuget/v1/FeedService.svc/" />
  </packageSources>
  <activePackageSource>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
  </activePackageSource>
</configuration>

The standalone nuget.exe can be downloaded here

This approach makes it easier to add custom feeds to all your jenkins jobs by changing the same config file.

Answer 3

NuGet Config files used by jenkins were as follows, fixing here worked in my case , hope it helps

Answer 4

[Windows] Be sure that the Jenkins service account has permission to see nuget package location. In my case, I was using a local admin account that didn't have the domain perms necessary to navigate the network location of our NuGet folder. Also, be sure the packages aren't nested too deeply.