Nuget package restore is a way to tell MSBuild to download any missing packages as a pre-build step.

This means that you can exclude your packages from source control, making your repositories smaller, faster to work with, and cheaper to back up (as you have just removed a bunch of binary data that is painful to merge and doesn’t change very often).

Enabling package restore through Visual Studio is easy:

  1. Right-click on your solution node and select "Enable NuGet Package Restore". alt text</p>
  2. Click "Yes" in the confirmation dialog. alt text

  3. When the installation is finished you'll have a new solution folder called ".nuget". alt text

This process adds a copy of nuget.exe to your solution. It also adds some MSBuild targets that integrate with your project files to download missing packages as a pre-build step. Check your .nuget folder into source control and anyone who donwloads your source will get nuget.exe and the MSBuild know-how to donwload missing packages as part of a build. This is awesome, but brings with it a risk: what happens if your dependencies are not available when you go to build them?

Imagine that a new dev joins your team, gets latest on your source tree, and one of your package dependencies is not available in the public feed? How do they build the project?
Perhaps the package is available, but not the version specified in your projects' packages.config files? You don't want your team randomly getting the latest and greatest version of a dependent package any time they want, because we want to manage the risk that our code might break by using different versions of our dependencies.
To manage these risks I recommend that you set up your own internal package feed. More on that next time.