NuGet is really a great tool, something that we’ve missed for many many years in the Microsoft World. But don’t expect it to be at the top yet, which is understandable due to his young age. However it’s improving and the latest version 1.6 just proves it!

Two ways to put under Source Control your NuGet package references

Let’s briefly describe these methods by starting with the first introduced in the tool

Full commit of packages

This method is kind of the “brute force” way to handle source control of the package: the whole content of the “packages” folder is put under source control.

Putting binaries under source control as a general practice is subject to many debates and I honestly couldn’t take a position. It’s supposed to be bad if your SCM tool can’t handle a big volume of data (for obvious reason) or if the bandwidth between your server and you is not great. Considering TFS capabilities (i.e. centralized model, compression of data exchange, storage on SQL Server) we’re pretty confident about storing a lot of binaries.

This method is the one used by default in Visual Studio, when you add a Package Reference to a project under source control, you get everything added to TFSC.

NuGet Package Restore

This method is the new one, supported from the version 1.6 of NuGet. It’s the answer to the many criticisms/remarks made to the NuGet team since the release of the tool. Where the “full commit” way could be harmless with SCM tools like TFS, it can’t be said so with tools like Git which apparently can’t handle without bad consequences the addition of so much binary data.

The Package Restore feature can be enabled by right clicking on the solution node in the Solution Explorer. When activating this feature, a new Solution Folder “.nuget” will be added to your solution and every project will be modified to use a new building target.

This new building target will check every time you start a build on a given project if the NuGet references specified by the packages.config file are present. If it’s not the case they will be downloaded and unpack.

This method is way lighter on the SCM side, the cost of NuGet is mainly the config files it adds to projects. The downside is the little extra time spent during compilation to check the existence of the packages.

Final word

Which way is better ? It’s a matter of taste, but personally I’ll use the Package Restore because even if TFS can handle the size of binaries, I prefer the light way. Considering the popularity of a distributed version of TFSC and the fact that TFS will be soon in the cloud you may not want to end up with a solution that doesn’t scale on the WAN.