For us .NET/Visual Studio developers, NuGet is definitely the best thing since sliced bread (okay, maybe not, but it sure is great!). If you don’t yet know what NuGet is, it’s basically a package- and dependency manager for Visual Studio and .NET. And if you haven’t started using it yet, you’re doing something wrong Winking smile

One thing that kind of always bothered me about dependencies is that it’s always been best-practice to have all your libraries checked in to SCM along with your solution. Typically by dumping them in a \Libs folder and referencing them from there.

But source control systems are generally not very optimized for handling binary files, and the size of your repository (and thereby performance) is negatively impacted by dragging around all these DLL files.

With NuGet this is a thing of the past! Using the command line NuGet.exe tool, you can point it at a local config file that tells it which packages to download for you (those of you who already use NuGet are probably already familiar with the packages.config file that lives under each project in your solution).

The only executable file I now have as part of my solution is the latest-and-greatest NuGet.exe which I place in a Tools folder in the root of my solution.

So, to get all this set up in your project, your first step is to create a Tools folder at the solution level of your project. Next, go ahead and grab the latest NuGet.exe from here and put it in your newly created folder.

Now, to each of the projects in your solution, add the following pre-build command:

$(SolutionDir)Tools\Nuget.exe install $(ProjectDir)packages.config -o $(SolutionDir)Packages

Also make sure that the \Packages folder is ignored by yout SCM system of choice (mine is Mercurial) in the same way that you always ignore the Bin and Obj folders.

To test, just delete the \Packages folder from your solution directory and try to do a build. NuGet should now automatically download all the dependencies you have and place them back in \Packages. It takes a little while to run the first time, so don’t panic if nothing happens for a few seconds. If it works and the build succeeds, go ahead and commit everything to source control. You can now continue working without the burden of large unsightly DLLs littering your source repository.