NuGet Package Restore Not Working

Question

I checked in a project on one computer, checked out on another, and find that the binaries installed by NuGet are missing. I could check them in to source control as well,

Answer 1

You have to choose one way of the following :

Re-installing a package by it's name in all solution's projects:

Update-Package –reinstall <packageName>

Re-installing a package by it's name and ignoring it's dependencies in all solution's projects:

Update-Package –reinstall <packageName> -ignoreDependencies

Re-installing a package by it's name in a project:

Update-Package –reinstall <packageName> <projectName>

Re-installing all packages in a specific project:

Update-Package -reinstall -ProjectName <projectName>

Re-installing all packages in a solution:

Update-Package -reinstall 

Answer 2

If anything else didn't work, try:

1. Close Project.
2. Delete packages folder in your solution folder.
3. Open Project again and restore Nugget Packages again.

Worked for me and it's easy to try.

Answer 3

In my case, an aborted Nuget restore-attempt had corrupted one of the packages.configfiles in the solution. I did not discover this before checking my git working tree. After reverting the changes in the file, Nuget restore was working again.

Answer 4

Sometimes something strange happens and using Visual Studio to automatically restore doesn't work. In that case you can use the NuGet Package Manager Console. That is opened within Visual Studio from Tools -> NuGet Package Manager -> Package Manager Console. The commands within the console are simple. And to get context help while typing a command just press the button and it will give you all options that start with the letters you're typing. So if a package isn't installed, for example log4net, type the following command:

Install-Package log4net

You can do a whole lot more, like specify the version to install, update a package, uninstall a package, etc.

I had to use the console to help me when Visual Studio was acting like a weirdo.

Answer 5

If the error you are facing is "unable to connect to remote server" as was mine, then it would benefit you to have this check as well in addition to the checks provided in the above comments.

I saw that there were 2 NUGET Package Sources from which the packages could be downloaded (within Tools->Nuget Package Manager->Packager Manager Settings). One of the Package Source's was not functioning and Nuget was trying to download from that source only.

Things fell into place once I changed the package source to download from: https://www.nuget.org/api/v2/ EXPLICTLY in the settings

Answer 6

I have run into this problem in two scenarios.

First, when I attempt to build my solution from the command line using msbuild.exe. Secondly, when I attempt to build the sln and the containing projects on my build server using TFS and CI.

I get errors claiming that references are missing. When inspecting both my local build directory and the TFS server's I see that the /packages folder is not created, and the nuget packages are not copied over. Following the instructions listed in Alexandre's answer http://nuget.codeplex.com/workitem/1879 also did not work for me.

I've enabled Restore Packages via VS2010 and I have seen builds only work from within VS2010. Again, using msbuild fails.My workaround is probably totally invalid, but for my environment this got everything working from a command line build locally, as well as from a CI build in TFS.

I went into .\nuget and changed this line in the .nuget\NuGet.targets file:

from:

<RestoreCommand>$(NuGetCommand) install "$(PackagesConfig)" -source "$(PackageSources)" -o "$(PackagesDir)"</RestoreCommand>

to: (notice, without the quotes around the variables)

<RestoreCommand>$(NuGetCommand) install $(PackagesConfig) -source $(PackageSources) -o $(PackagesDir)</RestoreCommand>

I understand that if my directories have spaces in them, this will fail, but I don't have spaces in my directories and so this workaround got my builds to complete successfully...for the time being.

I will say that turning on diagnostic level logging in your build will help show what commands are being executed by msbuild. This is what led me to hacking the targets file temporarily.