NuGet and projects under source control
NuGet is one of those awesome additions to Visual Studio that I wonder how I could have gone for that long without it. And as I am not the only one who likes it we had a bit of a discussion on Twitter last week about how to go about using NuGet with projects under source control that are shared by multiple users.
The problem is nothing new and has been around forever. Basically the problem consists of you installing some assembly, adding a reference to that assembly in your project and using the types in there. So far so good but what happens if you commit your changes to source control and another person does an update. If you didn’t add the assemblies used to source control they would have a broken build until they installed the same assemblies.
Nothing new, been there lots of times, and often solved by adding a solution folder named dependencies or something similar, dropping all external assemblies in there and putting those under source control. Of course that isn’t perfect, some assemblies are installed into the GAC and can’t be treated this way.
Adding NuGet to the mix doesn’t really have to change anything. All 3rp party libraries added using NuGet end up under a solution folder called Packages. By default this isn’t put under source control but there is no problem in doing so yourself.
However NuGet offers a far more interesting new way of solving the problem.
One thing NuGet does add to the project, and thus puts under source control, is the packages.config where all NuGet references and their versions are listed. In my sample project this file looks like this.
<?xml version="1.0" encoding="utf-8"?>
<package id="Ninject" version="22.214.171.124" />
<package id="Ninject.Extensions.Wcf" version="126.96.36.199" />
<package id="SuperAds" version="1.2" />
Now another developer can use the contents of this file to get exactly the same packages from NuGet and everyone is happy. The problem is that doing so manually would not be a nice way of doing things.
NuGet.CommandLine to the rescue
As it turns out there is a command line version of NuGet you can run from the Windows command prompt or a batch file that will let you do a project update based on this already present packages.config. David Ebbo blogged about doing this here but the basic approach is real simple. Make sure you have an up to date version of NuGet.exe and from the command line issue the following command:
NuGet install NuGetDemo\packages.config -o Packages
The result is NuGet downloads and installs all required packages and the project compiles again.
And if all required packages are already installed there is no issue, it just skips all of them.
While this may not solve the same problem with assemblies downloaded through other than NuGet sources it certainly works very nicely on those cases. Yet another reason for developer that publish assemblies on the internet to use NuGet because I will favor a NuGet package over another similar one any day.