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?
Restore packages manually using Visual StudioEnable package restore by choosing Tools > Options > NuGet Package Manager. Under Package Restore options, select Allow NuGet to download missing packages. In Solution Explorer, right click the solution and select Restore NuGet Packages.
In Visual Studio, use the Help > About Microsoft Visual Studio command and look at the version displayed next to NuGet Package Manager. Alternatively, launch the Package Manager Console (Tools > NuGet Package Manager > Package Manager Console) and enter $host to see information about NuGet including the version.
With NuGet Package Restore you can install all your project's dependency without having to store them in source control. This allows for a cleaner development environment and a smaller repository size. You can restore your NuGet packages using the NuGet restore task, the NuGet CLI, or the . NET Core CLI.
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>
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
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:
Config file locations and uses
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With