Managing external assemblies within source control

We all know how important source control is, without it writing code would be a nightmare. Along with your actual code, any other development items should be checked into source control – automated tests, manual tests, designs and documentation.

However, another important, often overlooked, items are external frameworks and dependencies. For example, in the past, I’ve generally only committed the main assembly of a unit testing framework (lets say xunit.dll).  While xUnit is a relevantly small framework, it still has additional assemblies which I didn’t require (such as the ReSharper integration) – well at least I thought I didn’t. Turns out life is much easier if you simply commit the entire framework with all dependencies instead of just the ones you need to build and run. If everything is committed, when someone wants to run your unit tests on a clean machine, they can do so without your interaction.

This hit me even harder with MVC releases. While I had commit System.Web.Abstractions.dll, System.Web.Mvc.dll, System.Web.Routing.dll for deployment, I mistakenly not included the actual installer. As a result, when I moved onto a different machine, I had a much harder time in getting the application up and running because I was missing the various parts of the Visual Studio integration.

If your not committing the entire framework into source control at the moment, I would really recommend you started.

Technorati Tags: ,

3 thoughts on “Managing external assemblies within source control”

  1. Agreed. Disk space is cheap nowadays. Pruning out a few assemblies is generally not worth the maintenance headache of having to figure out the required subset and keep it upgraded as it changes.

    We now check in most installers for small / moderate size stand-alone tools unless they are otherwise encumbered by license agreements governing redistribution.

  2. The other reason for following this procedure is to support your CI server — without the dependent ass’ys checked into your source tree, good darned luck getting your build server to run a successful build (which, incidentally, is one of the HUGE positive side-effects of deciding to do CI — you discover what’s needed but NOT in your source tree pretty quickly 😀 ).

Leave a Reply

Your email address will not be published. Required fields are marked *