"Unable to find version" during TFS Build 2015 when restoring NuGet packages

Question

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?

Ginzburg

Have you installed any of the Microsoft.CodeAnalysis NuGet Packages? I did and I started getting these errors, when I removed all of those then it started working again. – Stroup

@Stroup I don't have this NuGet package – Carloscarlota

Answer 1

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> 

Ginzburg

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. – Catenate

nuget.org/api/v3 -- This location does not exist (the api.nuget.org/v3/index.json does)... and the two keys defined here both have the same ID ("nuget.org") – Bellbird

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: <?xml version="1.0" encoding="utf-8"?> </configuration> – Hebrides

Answer 2

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

Tigon

Answer 3

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

Gelt

Nice addition. It seems like the issue has many workarounds/solutions depending on the particular case! – Carloscarlota

Answer 4

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.

Information