18

I'm having troubles with NuGet package restoring during a TFS Build 2015.

Since some packages require NuGet 3.x client, I've configured the new scriptable build to use a custom NuGet location where I've placed the executable of NuGet Command-Line 3.x beta.

Whenever I run a build, all packages can't be restored and NuGet throws the "Unable to find version..." error:

Unable to find version '1.1.10' of package 'Microsoft.Bcl'.
Unable to find version '4.0.10' of package 'System.Threading'.
Unable to find version '1.1.37' of package 'System.Collections.Immutable'.
Unable to find version '1.0.0' of package 'Owin'.
Unable to find version '4.1.0' of package 'NLog'.
Unable to find version '7.0.1' of package 'Newtonsoft.Json'.
Unable to find version '2.0.1' of package 'MongoDB.Driver.Core'.
Unable to find version '2.0.1' of package 'MongoDB.Driver'.
Unable to find version '2.0.1' of package 'MongoDB.Bson'.
Unable to find version '3.0.1' of package 'Microsoft.Owin.Security.OAuth'.

...and even more packages. I believe the issue is clear.

When I build the same solution in the build machine using Visual Studio, all packages are restored sucessfully.

How do I solve this?

Matías Fidemraizer
  • 63,804
  • 18
  • 124
  • 206

4 Answers4

24

In my case, the issue was that user-wide NuGet.config located at C:\Users\[User name]\AppData\Roaming\NuGet\NuGet.config (where [User name] is the user who's running the build agent's Windows service) was pointing to NuGet API v2 while my build is already using NuGet Command-Line 3.x.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <!-- CHANGING V2 TO V3 IN THE URI VALUE SOLVED THE ISSUE! -->
    <add key="nuget.org" value="https://www.nuget.org/api/v3/" />
  </packageSources>
</configuration>
Community
  • 1
  • 1
Matías Fidemraizer
  • 63,804
  • 18
  • 124
  • 206
  • I had a similar problem but only when trying to install a package via the Package Manager Console; the Package Manager Dialog worked fine. This answer pointed me in the right direction: It was the URL of the package source. In my case the URL in Nuget.config had said `"https://www.nuget.org/api/v2/"`. When I removed the "www", to change it to `"https://nuget.org/api/v2/"` it worked. – Simon Elms Apr 25 '16 at 12:20
  • 5
    https://www.nuget.org/api/v3/ -- This location does not exist (the https://api.nuget.org/v3/index.json does)... and the two keys defined here both have the same ID ("nuget.org") – CJBS Oct 21 '16 at 21:15
  • In my case the 3rd version was allready pointed in the config. I've just removed all the content of config file and it helped: – David Apr 04 '17 at 13:00
3

In my case the Nuget.Config, was in:

C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\NuGet

So search for Nuget.Config in your C:\.

The user depends on the account that you configured the Agent

coatless
  • 20,011
  • 13
  • 69
  • 84
willianleite
  • 77
  • 8
2

If for some reason updating the NuGet.config in the Roaming folder is not an option or unwanted, it is also possible to add the config file to the solution root.

According to the docs:

  • Project-specific NuGet.Config files located in any folder from the solution folder up to the drive root. These allow control over settings as they apply to a project or a group of projects.
  • A solution-specific NuGet.Config file located within a .nuget folder in the solution. Settings in this file apply only to solution-wide packages and is supported only in NuGet 3.3 and earlier. It is ignored for NuGet 3.4 and later.

Config file locations and uses

Emiel Koning
  • 4,039
  • 1
  • 16
  • 18
0
  1. Your project folder must contain 'packages' folder and in that 'packages' folder all of the packages dlls should be present.
  2. Your project references should point to those packages dlls.
Julia
  • 1