TFS, VS2008: How to deal with external assemblies

Question

We have various solutions with various numbers of projects in them. All checked in to a Team Foundation Server source control thing. Most of them builds as Class Libraries.

Anyways, we now want to use some 3rd party external assemblies in our project. And I am wondering how to best do that. Cause we of course want to have those assemblies so that everyone can build without trouble, and also so that we know where we have them. So I am thinking that they should be in the source control with the rest of the code. Which they probably should be. But where? Where do you put stuff like this?

I put the first one in a folder in one of the projects, but I see now that that is perhaps a not so good idea, since I would like to use them in many of the other projects as well. So what do i do? Should I create an empty bogus project for external assemblies? Should I just create a folder for them in source control? How do you guys organize these things?

Answer 1

The third-party assemblies on which your project depends should definitely be in source control. Your build process should be able to get everything it requires (except operating system and core .NET framework stuff) from source control. You should not require specific third-party software to be installed on your build machine..

Here's how I tend to organise this stuff in TFVC:

Create a separate team project called something like "Common" or "Shared" to hold these third-party binaries.

Branch the binaries as required over to a "Solution Items" folder in each project that requires a reference to these assemblies.

So, for example, you might end up with something like this structure:

$
|-Common
| |-Binaries
|   |-Microsoft
|     |-EnterpriseLibrary
|       |-2.0
|         |-Microsoft.Practices.ObjectBuilder.dll
|-YourTeamProject
| |-Branches
  |-Trunk
    |-Source
    | |-Solution Items
    | |  |-Microsoft.Practices.ObjectBuilder.dll
    | |-YourProject
    |-Tests

where the copy of the MS dll in YourTeamProject is a branched copy of the assembly in Common.

When referencing the third-party binaries from your project, be sure to use relative File References to the copies of the dll in your "Solution Items" folder. In this way everyone on the team knows where to find the binaries that are referenced by the various projects in your solution, and the relative paths should be the same for each member of your team.

In this way, you only have a single copy of each version of the third-party assembly in your source control. Also, should the third-party release a bugfix version of the assembly, you can update your copy in Common, and merge the changes across to all your projects which make use of it.

Answer 2

Create a new folder under your TFS solution, for instance shared libraries, and dump the assemblies in there.

Answer 3

We keep them under the branch, in a Binaries directory:

$/project
  - Main
     - Binaries
     - Source

Then they branch and version as needed. Although, Ian's way might work better if you have larger needs.

Answer 4

I had a question similar to yours, and came across the following link: Managing Source Control Dependencies in Visual Studio Team System

It goes into significant depth on four different dependency management scenarios. The article advocates what appears to be a similar branching solution to the one Ian Nelson mentioned.