44

I have a VS solution and as part of a TeamCity Build, we restore packages from both a private NuGet feed (myget) and the public feed (nuget.org). Most packages restore fine, but it hangs on the ones below for WebApi and Mono.Security. This is all working locally in Visual Studio.

[restore] NuGet command: C:\TeamCity\buildAgent\plugins\nuget-agent\bin\JetBrains.TeamCity.NuGetRunner.exe C:\TeamCity\buildAgent\tools\NuGet.CommandLine.DEFAULT.nupkg\tools\NuGet.exe restore C:\TeamCity\buildAgent\work\953bd084b49f7d88\DataFinch.Web.sln -Source https://www.myget.org/F/datafinch/auth/<hidden>/api/v2 -Source https://api.nuget.org/v3/index.json
[11:41:35][restore] Starting: C:\TeamCity\buildAgent\temp\agentTmp\custom_script473789219385667038.cmd
[11:41:35][restore] in directory: C:\TeamCity\buildAgent\work\953bd084b49f7d88
[11:41:35][restore] JetBrains TeamCity NuGet Runner 8.0.37059.9
[11:41:35][restore] Registered additional extensions from paths: C:\TeamCity\buildAgent\plugins\nuget-agent\bin\plugins-2.8
[11:41:35][restore] Starting NuGet.exe 2.8.50926.602 from C:\TeamCity\buildAgent\tools\NuGet.CommandLine.DEFAULT.nupkg\tools\NuGet.exe
[11:41:43][restore] Unable to find version '5.2.3' of package 'Microsoft.AspNet.WebApi.Client'.
[11:41:43][restore] Unable to find version '5.2.3' of package 'Microsoft.AspNet.WebApi.Core'.
[11:41:43][restore] Unable to find version '3.2.3.0' of package 'Mono.Security'.
[11:41:43][restore] Unable to find version '6.0.4' of package 'Newtonsoft.Json'.
[11:41:43][restore] Process exited with code 1

Teamcity config: enter image description here

Scott Weldon
  • 9,673
  • 6
  • 48
  • 67
Chris Kooken
  • 32,730
  • 15
  • 85
  • 123
  • did you add the private source to the Nuget.targets? https://docs.nuget.org/consume/package-restore – Tony Sep 02 '15 at 18:33

6 Answers6

46

Try using https://www.nuget.org/api/v2instead of https://api.nuget.org/v3/index.json per the nuget docs: https://docs.nuget.org/consume/Command-Line-Reference.

rarrarrarrr
  • 1,129
  • 13
  • 18
  • 1
    Works for me again when I switch from v2 to v3. Thank you for the hint. – timmkrause Jun 29 '16 at 12:06
  • 2
    Or upgrade the nuget.exe, it will use the new URL by default. – xmedeko Jun 30 '16 at 09:11
  • 3
    I was having trouble using a _new_ private NuGet feed with an _old_ version of `NuGet.exe`. To fix that, open a command prompt, `cd` to your `.nuget` folder, and run `.\NuGet.exe update -self`. – Phil Sep 09 '16 at 17:24
  • I ran into the same issue after installing NuGet on Debian (`NuGet Version: 2.8.1.0`), and switching to the v2 API fixed it for me. – Scott Weldon Nov 11 '16 at 18:17
  • 1
    I had the same problem but I had the "Packages Sources" field blank because it said "leave blank to use NuGet.org." This worked for a long time, but I tried queuing up a build recently and it was showing me the same behavior as Chris Kooken was seeing. Once I added the source https://www.nuget.org/api/v2 into the field, it started working. I'm not sure what changed to cause this, but this answer certainly helped me. – tjans Nov 21 '16 at 14:51
  • This got me in the right direction. The url I needed for my local nuget server was in index.json. – Brandon Griffin Dec 07 '16 at 21:28
3

The reason why the build failed, was an old version of nuget.exe. I finally solved this problem by downloading the latest version and put this executable in the Program Files x86 folder. Then I created a new system variabele to point to this executable. After that I add a NuGetInstaller package in my TFS Build Definition to let me configure TFS using this new NuGet.exe. This link helped me to let TFS use this new NuGet version

SwissCoder
  • 2,514
  • 4
  • 28
  • 40
Marcel Beeker
  • 163
  • 1
  • 13
  • I did something similar to what you described, but instead of creating a system variable I put the current NuGet.exe (5.11.0) into a folder available to the build agent on the TFS 2015 build server. Then I put the fully qualified path to NuGet.exe into the build def. That fixed most of my NuGet problems, but not for 3 packages Newtonsoft.Json, Antlr and WebGrease. – Rod Oct 07 '21 at 20:24
1

I followed this: https://blogs.msdn.microsoft.com/tfssetup/2017/04/18/tfs-2017-update-1-nuget-restore-task-always-fails-trying-to-find-packages-even-though-they-exist-on-the-feed/

I had tried 3.3 and got this error:

Restoring NuGet package Microsoft.AspNet.WebPages.3.2.3. WARNING: Unable to find version '3.5.0.2' of package 'Antlr'.

I downloaded the latest NuGet 4.3.0.4406 and set the Custom path to NuGet and that failed as well.

Surprisingly when I switched to 3.5 it worked.

enter image description here

If you are really stuck, run the command in a Command Line Prompt and it will work:

C:\Program Files (x86)\NuGet\nuget.exe restore -NonInteractive E:\agentXYZPool\_work\1\s\xyz.sln
Jeremy Thompson
  • 61,933
  • 36
  • 195
  • 321
0

I ran into this problem with one of our build slaves leveraging TFS and Visual Studio.

The way I fixed it was, I opened the solution that wasn't compiling in Visual Studio, right-clicked on the SLN and selected "Enable Restore NuGet Packages"

That prompts a dialog box that you have to accept. After you've done that, you might be good to go. Right-click on the SLN again and run "Restore NuGet Packages", and if that operation succeeds, you're golden.

There's probably some setting you can adjust programmatically when setting up your slave environments, but that's one direct way to fix this kind of problem.

kayleeFrye_onDeck
  • 6,648
  • 5
  • 69
  • 80
0

According to THIS current document as of this writing from MS, the proper url is: https://api.nuget.org/v3/index.json

So I went about to fix the issue because I assumed it had nothing to do with the URL. I did 2 things, not sure which it was that resolved the issue but I'll post both here in case it helps someone.

  • Within TFS2018 and within my build step for the installation of Nuget I specified version 4.9.3 (the reason I chose 4.9.3 because I noticed by looking at detailed log of VS that during my build it was using this version) and chose to always download the latest version.

  • Second thing I did was I removed a Nuget.Config file from my project that was left over from something I was testing. Then I re-commited my changes to TFS

After I did both of the above steps the rest of my build started working.

Post Impatica
  • 14,999
  • 9
  • 67
  • 78
0

Using an old version of Visual Studio's Nuget

  • Visual Studio has C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\Nuget.exe. Jenkins was using that to nuget restore
  • Updated Nuget in program files, 
    C:\Program Files (x86)\NuGet> ./nuget.exe update -self
  • Pointed Jenkins at that new Nuget path and cooking with gas 
    SET PATH=%PATH%;C:\Program Files (x86)\NuGet
nuget restore SolutionName.sln
fusion27
  • 2,396
  • 1
  • 25
  • 25
  • Visual Studio 2019 Professional does not come with nuget.exe. Instead, it comes with a PowerShell module for NuGet. A stand-alone nuget.exe can be downloaded from https://learn.microsoft.com/en-us/nuget/install-nuget-client-tools, but changing Visual Studio's NuGet configuration to search the v2 NuGet repository resolved my issue (see other answers). – MikeOnline Sep 24 '21 at 20:02