ThoughtShapes Shaping Ideas With Thought

On any given project, we typically have a ThirdParty directory where we house all our third-party assemblies that we reference. Inside of that directory we create directories representing each assembly or set of assemblies. For instance, we usually have a ThirdParty directory that contains a directory for each NUnit version we've used on the project at any given time. If we were to start a project today, we'd have a ThirdParty directory that contains an NUnit-2.4.2-net-2.0 directory (since that is the latest NUnit version). We like to include the version number on the directory in case we make use of multiple versions of the same assembly at any given time on the project. This gives us the freedom we need to reference what we want to when we want to.

In the case of NUnit, we have two tips. The first is to never, ever install it on your machine. I’d love to speak with the NUnit people and ask them not to create an installer, and instead just tell people to run their nunit-gui.exe or nuni-console.exe file, since NUnit has never given me a problem when using plain ol’ xcopy deployment. The big reason for this is because if any of the developers on the team have NUnit installed, it's inevitable that at some point in the project they end up inadvertently pointing to the nunit.framework.dll assembly in their GAC (Global Assembly Cache). When the team changes to a newer version of NUnit there is always a headache dealing with figuring out why such people can’t build or, worse yet, they have some problem that no one else is having and it takes a lot of energy to figure out why. So, don’t install NUnit and instead just reference a downloaded DLL.

The other tip that isn’t a huge issue but helps keep things clean is to only include the necessary DLLs from NUnit in the directory you house them in. Here are the DLLs you need in the three most common scenarios:

1. If you run your NUnit tests in your test project(s) using an NUnit runner tool such as Resharper (and not the NUnit Console or GUI executables), then you only need to include the nunit.framework.dll in your directory. We’d have something like this:

   ThirdParty
       -NUnit-2.4.2-net-2.0
           -nunit.framework.dll

2. If you run NUnit using the NUnit console, or you occasionally run a tool such as NCover (which uses the NUnit Conole executable), here is the layout with only the necessary files:

   ThirdParty
       -NUnit-2.4.2-net-2.0
           -nunit.framework.dll
           -nunit-console.exe
           -nunit-console-runner.dll
           -nunit-core.dll
           -nunit-util.dll

3. If you’re going to run NUnit with their GUI executable here is what you’d need:

   ThirdParty
       -NUnit-2.4.2-net-2.0
           -nunit.framework.dll
           -nunit-gui.exe
           -nunit-gui -runner.dll
           -nunit-core.dll
           -nunit-util.dll
           -nunit-uikit.dll

Also, if you use the NUnit mock framework at all, you’ll need the nunit-mocks.dll as well.

What we typically do is to include all the necessary DLLs that can accomplish all of the above situations, so that anyone can do what they feel is necessary. This favors practicality over perfect cleanliness. Having said that, here is what our directory layout usually looks like:

ThirdParty
    -NUnit-2.4.2-net-2.0
        -nunit.framework.dll
        -nunit-console.exe
        -nunit-gui.exe
        -nunit-console-runner.dll
        -nunit-gui -runner.dll
        -nunit-core.dll
        -nunit-util.dll
        -nunit-uikit.dll
        -nunit-mocks.dll

You definitely don’t need to have the NUnit source in your source control system unless you’re building the DLLs and EXEs yourself for some reason or other, and you definitely don’t need the documentation. Keeping things nice and clean like this makes it easier for everyone to pull down all the files from your source control system, since there are a lot less files to pull down. This especially comes into play when you have a lot of branches to pull from. Cleanliness is Godliness.

And, branch-tangentially speaking, I should say a hallelujah for Subversion’s wonderful branching ability. A beautiful thing, it is.