Can TFS Projects Reference Each Other?

Question

I've recently begun working in an enterprise software environment with hundreds of different applications all confined to their own "silos." One of my tasks is to try to standardize things a bit, and the first attempt will be a standard event logging. Currently, the company's "standard" is "everyone should use Enterprise Library for logging." What this translates to in reality is that different developers working on different projects implement different logging in different ways, and just most of the time use that library.

To that end, I'm looking to abstract out the actual logging tool behind a "company standard" internally-developed interface. The idea is to move the focus of what a "standard" is away from the implementing tool and towards how it's used. Applications would then use the internal library and not concern themselves with the tool behind the scenes (save for maybe an app.config section, though I already know how to abstract that out with log4net).

However, a problem I'm facing right now is that all of these applications are in separate TFS projects. If I create a project that contains a common library for logging, is there any way for the other projects to reference it? I don't want to distribute the library among each project because they'll get out of sync quickly.

If TFS can't do this, does anybody have any other suggestions?

Answer 1

Jeff's suggestion is the closest to what we would recommend. Consider internal APIs a seperate team project which serve other projects as clients. Those project feed the backlog and the release cycles. You can have CI, Beta, and Release builds as you see fit. Consuming/consumer projects then do is use their selected build as they can appropriately accomodate in their own release cycle. Because your TFS builds will push to a drop location made available, people pull rather than you pushing new releases. Pull is selecting and those assemblies should be checked-in and version controlled within the consuming project. This is no different than you would do with a true 3rd party assembly, in fact you should consider these in the same light.

When consuming applications have the need or bandwidth to upgrade to your newer versions of the internal assemblies, they pull.