Problem: Your project uses 3rd party DLLs and you’re trying to figure out how to manage these appropriately in Team Foundation Server (TFS) version control.

Solution: Add the DLLs to a folder in source control and reference these using relative paths.  Optionally, use NuGet to help manage these dependencies.

The Discussion

Let’s say that you’re using Enterprise Library Data Access Block or WebGrease or some other 3rd party library. Your code depends on that to work and your project file (*.csproj, *.vbproj, etc) needs those libraries to be in a particular location on disk in order to compile the code.  I’ll usually create a directory off of my “solution root” (aka. the directory that contains my *.sln file) called either CommonDlls or Binaries as shown in Figure 1.

Figure 1 – CommonDlls folder off of my solution root

I’ll then put my binary dependencies (aka. the 3rd party DLLs) into this directory.  (see figure 2)  In my Visual Studio Projects, whenever I need to reference one of these 3rd party binary dependencies, I’ll *always* refer to it in this CommonDlls directory and now Visual Studio will refer to those DLLs using a relative path.  I’ll also add this directory to TFS source control so that the directory and its contents are versioned just like everything else in my software development effort.

The combination of this DLLs being in TFS source control and also being referenced via a consistent, relative path means that this solution should compile on anyone’s machine without having to tweek anything.  Put another way, anyone who does a “get latest” on the solution root and then opens this solution should be able to compile immediately without having to do anything special.  As a developer, this makes your life so much easier because making your code compile is brain-dead simple.  This also makes your automated builds ultra-simple, too.

Figure 2 – The binary dependencies for this solution in the CommonDlls folder

So here’s a quick review of the steps:

1. Create a subfolder off of your solution root that will contain your binary dependencies
2. Add your binaries to this folder
3. From your Visual Studio projects, when you need to “Add Reference”, always refer to the DLLs in this folder
4. Add this binaries folder and the DLLs to source control and check it in

Done.  Your binary dependencies are now under version control just like the rest of your source code.  The important thing here is that you know *KNOW* what version of the DLLs you’re compiling against when you do a build.  If you know what you’re compiling, you know what you’re testing.  If you know what you’re testing, you know if everything works together.  Hopefully that means that what makes it to production works, too.  Most importantly, you’ll know what versions of everything that you’ve deployed to production.

Dealing with Updates

The next big question is what do you do when you need to update that binary dependency with a new version of the DLL?  Well, it’s totally brain-dead simple.

1. Make sure the solution is closed
2. Go to the binaries folder using Source Control Explorer
3. Check out the files (DLLs) you want to modify
4. Open the binaries folder using Windows Explorer (explorer.exe)
5. Drop the new versions of the DLLs into the folder
6. Open the solution and make sure it still builds
7. If it builds, check everything (any code changes plus the updated DLLs) back in.

Done.  Your binary dependencies are updated.

NuGet Makes Stuff Easier

Have you checked out the integration between Visual Studio and NuGet yet?  It’s pretty slick.  NuGet is a magic repository in the sky (cloud?) that helps you to download and manage dependencies on 3rd party libraries.  Basically, if the library you want is available on NuGet, you can do exactly what I described above except easier.  Let’s say that you’re doing WPF development and you want to use the MvvmLight libraries in your ViewModels.  In Visual Studio 2012, you’d go to the Package Manager Console and type “Install-Package MvvmLight” (see Figure 3) and then NuGet will download the appropriate libraries to disk, modify your project to add references to these DLLs, and add these DLLs to source control.

Figure 3 – Install MvvmLight using NuGet and the Visual Studio 2012 Package Manager Console

If you use the NuGet integration like this, it will create a folder off of your solution root named “packages” and the binaries that you’ve downloaded into this folder as shown in Figure 4.  It will also add some configuration data that will help you to manage updates to these libraries in the future.

Figure 4 – The NuGet packages folder, the NuGet repositories.config file, and the downloaded packages

After you’ve installed the DLLs packages from NuGet, it’s probably a good idea to make sure that the packages folder and everything in it has been added to TFS source control and checked in.

Summary

If you have dependencies on 3rd party DLLs, you’ll definitely want to put them in to source control.  You can either manage them manually or, if they’re available on NuGet, you can use NuGet’s automation features to help manage these packages.

I hope this helps you out.

-Ben

-- Trying to figure out what the best way is to manage your binary dependencies?  Is your Team Foundation Server (TFS) source control repository kind of a mess?  Looking to migrate your code from something else into TFS? Drop us a line at info@benday.com.