I was trying to solve an automated build issue with an external project yesterday. The issue was that we had a bunch of nuget dependencies that we don’t include in source control (and you shouldn’t), but the solution wasn’t setup to automatically download those nuget references (aka “Package Restore”).
As of Nuget v2.7, package restore is automatically integrated with your Visual Studio build process – meaning that if you haven’t manually updated your nuget references, the next time you try to build the project in Visual Studio it will automatically download any missing libraries for you. This is great, but only works within Visual Studio. You also have the option of “opting out” of automatic package restore, but it only works on a computer-basis; you can’t opt out on a solution level (which would be nice).
Before v2.7, you had the option of right-clicking a project and selecting “Enable Nuget Package Restore”, which effectively placed a copy of nuget.exe in your code folder (under “.nuget”) and modified your build scripts to run it manually. Also a great option, but it does require a manual step and adds an exe to your codebase.
The third option is using the nuget.exe tool from the command line, which you can do from anywhere as long as you have a copy of the EXE.
This command will parse through your solution, look for nuget references in your projects, and download anything that’s missing to the normal “packages” folder. What’s better, is that you can include this in your automated MSBuild scripts on a build server.
All three of these options essentially do the same thing, I just prefer the command line option because I can include it in our powershell script. You can usually find nuget in an %AppData%\Local\Nuget folder.