Nuget is cool.
What is not cool is when you push a project to source control and include a ton of installed packages, bulking up your repo with stuff that could be easily pulled in via Nuget by anyone cloning your project. However, what was equally irritating was having to include instructions for what packages need to be installed, if they were excluded from the source repo.
Enter Nuget Package Restore.
Before you can avail yourself of Nuget Package Restore, we need to explicitly allow this behavior on our machine. This is required on a per-machine basis before Nuget can restore packages for a solution automagically, and can be set in Tools => Options => Package Manager:
Visual Studio Options Menu:
Package Manager Settings Dialog:
Now that our machine has been told it is ok to restore Nuget Packages automatically, we need to enable this behavior in our specific solution as well.
To enable Nuget Package Restore in our specific solution, right-click on Solution Explorer => Your Solution => Enable Package Restore:
Enabling Nuget Package Restore for a Specific VS Solution
This may take a few seconds. When VS is done processing, an examination of Solution Explorer reveals a new folder at the root solution level:
Files Added to Solution by Nuget Package Restore
Notice the NuGet.exe file in there? This file is required when, for example, someone clones your project from source and attempts to build with Nuget Package Restore enabled. Therefore, it needs to be committed to source control.
We also now want to exclude all the package files from source by editing our .gitignore file (I am assuming Git as the source control provider, but the principle here applies to whichever provider you are using – you need to tell your version control system what to include in the repository and what to keep out).
A typical ASP.NET MVC 5 project created from the standard VS 2013 template will contain (as of this writing) 161 files from various Nuget packages included as part of the default solution. This is some significant bulk. Using the default .gitignore file (or any of the most common in use for Visual Studio/C# projects) the total number of files which will tend to be included as part of the project repo numbers over 200. Note this is after excluding all the binaries and VS housekeeping files. In other words, nearly 75% of the common files in a VS 2013 ASP.NET MVC 5 solution consist of Nuget packages, which can now be restored automatically instead of pushed up to our repo.
To cut down the bulk, lets modify our .gitignore as follows. Note, your .gitignore (or .hgignore, or .tfignore, what have you) will most likely look a little different than mine. That's okay, because we're only going to do a few small tweaks to the file – keep the rest the same.
Open your .gitignore file and add the following line to exclude the packages folder from source:
Ignore Packages Folder in .gitignore
packages*/
Most likely, your .gitignore file already excludes files with the .exe extension. We may want to make an exception for Nuget.exe, since it will be needed to restore packages by anyone cloning our repo:
Look through your .gitignore until you find the following:
*.exe
Then add this right AFTER it (the order here is important):
*.exe
!NuGet.exe
The above tells Git to ignore .exe files, but to make an exception for NuGet.exe.
Another option (pointed out by a commentor on G+), if you don't want to clutter up your .gitignore, is to use the following command, which force-adds the (otherwise ignored) Nuget.exe file to the git staging for commit:
$ git add -f Nuget.exe
The step(s) above are optional, since someone cloning your solution could simply Enable Nuget Package Restore for the solution, at which point the NuGet.exe would be installed. However, this saves the step.
Now, we no longer need to include all the installed Nuget package files in our source repo. However, we should probably add a blurb to the README.txt file (or otherwise inform consumers of our code) letting users know that they will need to perform the VS configuration needed to allow Nuget to restore packages as described in the first step in this article.
