Sharing common libraries in a large team & tracking what version of the libraries are being used

Question

I belong to a .NET shop using TFS. In the last year or so we've been trying to share and between our teams (some local, some in a completely different region).

Up until now, we've included shared code as project references. As the dependency on the shared code grows, we're getting into more and more problems (people modifying code that breaks other apps, updating project to new version of Visual Studio, etc.). As a result, I'm leaning toward having people reference the code as compiled binaries (dlls). The code itself will be maintained and regularly updated by an assigned team. Source code will be available as read only so that people can make changes/patches and submit it to the owning team for review and redistribution. What do you think of this plan? Is there a better way?

I feel that the downside to this plan is that I'm trading in one set of headaches for another. If I have many different versions of a library, how can I know for sure which versions are being used and which aren't? Is there a way to do this through TFS? I believe that if we know exactly what versions are being used, we can know to what extent we have to worry about backward compatibility, who to contact if we have concerns, etc.

How are some of you folks on large teams handling this?

Answer 1

reference the code as compiled binaries (dlls)

This is a good idea. In the short term, shared project references can feel easier, but it makes things more difficult unless you have good regression tests. Even then it is better to consider shared libraries a project/product in-and-of themselves. Have a backlog and Team Project dedicated to that deliverable.

can I know for sure which versions are being used and which aren't

My first question is, why do you care? Allow those that depend on the shared libraries to upgrade and adopt new versions as their particular timeline and bandwidth allows. The primary reason you'll likely require consuming projects/products to upgrade is to deal with depreciated features or rules. For instance, you may be deploying a common crash reporting library that depreciates a mechanism for sending a crash report because you are now requiring HTTPS. Older versions no longer will work. In this case, communication is going to be your best bet, but you could run a script over all the assemblies found in TFS to look at the assembly version.

Answer 2

How can I know for sure which versions are being used and which aren't

A couple things:

• Maintain as much isolation as you can between your app code and your libraries. Use interfaces that are nice and stable.

• Make your developers responsible for getting the most recent versions of the libraries before they do their local work / compiling. Personal individual responsibility is a good thing.

• Worry about the interfaces during your builds. Make sure your build gets the latest version of the libraries before it builds. If your developers have made a mistake, it will become apparent here.

• Only use your official builds for testing and release. Local builds can be used for some unit testing, but once you get to integration, only official builds should be acceptable.

Answer 3

We do distribute assemblies across different teams. If a method or an overload must be changed in a specific version, we preserve old method as [Obsolete("message")], add new method and then in next versions we remove deprecated method. This way, developers have enough time to use newer versions.