TFS2012: How to deal with binary dependencies in source control

Posted · 4 Comments

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. 


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.



— 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

4 Responses to "TFS2012: How to deal with binary dependencies in source control"
  1. Duncan Faulkner says:

    Hi Ben,

    Great article, the only thing I would add to this is I wouldn’t (and don’t) check Nuget packages into TFS (in fact I explicitly exclude this folder from TFS).

    If you right click on a solution and select “Enable NuGet Package Restore”, this will add the NuGet.exe to your solution, when a developer pulls the latest version from TFS and builds the app (the only requirement after getting the latest version), NuGet will pull down and install any missing packages, based on the information in the packages config file.

    This should also work for build automations.

    • Ben Day says:

      Hi Duncan,

      Good tip. My instinct is to add them to source control so that you know they’ll be available and to isolate you from any potential NuGet outages. That said, I’ll bet that there are some great reasons to not add them.

      Can you sketch out some of the pros and cons of adding NuGet packages vs. not adding?


  2. Don M says:

    One more vote for nuget + no binaries in source control. We’re using distributed version control and it is nice to keep the repos small.

    Also, you only need nuget to be up once to download all your binary dependencies, so a nuget outage is not really an issue.

    We have a hosted private nuget feed and use it for all internally shared binaries and 3rd party binaries that aren’t on the official nuget feed.

    I think it works very well.


  3. Hi Ben,

    This article really helped me on our development environment, since we started our migration from SVN to TFS.

    However, we are having some trouble white 3rd party DLLs.

    I follow your steps but when I drag the DLLs from Windows Explorer to the Team Explorer, it does not allow to check in the files. It just says “This item cannot be added because a file already exists at its destination local path.”.

    I figured out how to perform the check in, but only deleting the versioned files from Source Control before adding the new ones from Windows Explorer.

    Am I missing something?

    Thank you very much!


© 2016 Benjamin Day Consulting, Inc.
Brookline, MA
617-645-0188 | |