Here’s a quick post on how and why you want to consider using NuGet package restore.

First, if you’re unfamiliar with NuGet, it’s basically “add reference” to external software projects (typically open source ones such as jQuery, but also for Microsoft ones such as Entity Framework). You definitely need to check out David Ebbo’s post introducing it. NuGet will change the way you develop.

Now when using NuGet it maintains a packages folder near your solution file. For things like ASP.NET MVC that heavily leverage NuGet, you’ll see this folder is very large. It’s usually much larger than your project itself in the beginning.

If you write small projects and share them out as compressed files (e.g. zip’s), and size matters to you, you might want to consider enabling NuGet package restore (off by default) for those projects and delete the packages folder before zipping and sending it out.

As an example, with a typical MVC 4 project, the “raw” content is 680 KB. After doing a build and counting the packages folder you’ll see it jumps to 16.9 MB. If that helps you significantly, then it’s probably a good idea to use package restore.

Three things have to happen to use NuGet package restore.

First, you’ll need to make sure everyone who downloads your zip file has “Allow NuGet to download packages during build” enabled in Visual Studio under Tools>Options>Package Manager.

The next set of steps are only done by the you – the one sharing the code. Right-click on the solution file and choose enable package restore:

After doing this, you’ll see 3 new files in your solution:

Finally, when you zip and share your code, be sure to include the .nuget folder but not the packages folder (and maybe not the bin and obj either).

Now I did say at the beginning why to consider this, not just you should use it as a blanket statement. This whole workflow was introduced for simplifying source code management. Two reasons that come to mind right away to not use package restore are:

1. If not many of your users / readers / downloaders have package restore enabled globally it might be more effort than its worth.
2. In the source code scenario, you are dependent on NuGet keeping the right version around forever. Suppose you want to roll-back to the way the code was 2 years ago (some time in the future). It might be safer to have the packages folder just checked in so you’re sure it gets versioned and labeled exactly right.

Hope that’s useful to you!

Cheers,
@mkennedy