Actually it isn't that complicated (once the initial configuration is completed ;-). Several custom tasks help the project only retrieve what references are listed in the project as "Binary Library References" (which is as simple as removing the HintPath element). These tasks also make sure that that what the developers are getting is what has been deployed into the integration test environment (but allows them the flexibility to use whatever version they are interested in, including those assemblies that have been delivered to production). The idea is that you can have several developers working on different parts of the application, and yet still be at the tip of any dependent development (without having to worry about updating a reference path or setting a link).

Once I have configured a project to use the Binary Library, the developer no longer has to worry about whether they are up-to-date on any references. They also don't have to worry about their build compiling a bunch of dependent projects that they haven't touched and may not have been touched in months. Their build times decrease, and the amount of information that they have to worry about shrinks, allowing them to focus on the task at hand. And if, by some fluke, bad code gets checked into the system, breaking a component they don't own, but rely on, they won't see it and will not be affected by it. However, on the flip side, if the component that they rely on changes one of its API method signatures, it will still break their call and they can then communicate with the other team and make the necessary changes to their own component.

We have a similar situation at my company. This question ahs come up before in the forums. Here is a blog post I wrote about a similar question (saves me from typing it again ). http://sstjean.blogspot.com/2006/09/team-build-how-do-you-deal-with.html

- Steve

To ensure that the newest reference binaries are used, we rely on our Continuous Integration (CI) system. Every time the CI build runs (every 10 minute interval that has at least one check-in), it goes out to the "corporate reference library" to get it's dependencies from the previous night's enterprise build. When the enterprise build runs each night, it stages out all of the binaries created to a central DFS share for the CI builds to grab. If dev team A makes a change to A.dll, that change gets picked up in the nightly enterprise build. The next day when team B's CI build runs for the first time, it will grab the new A.dll from the corporate reference library and build against it. If the changes to A.dll are incompatible with team B's code, the CI build fails and team B looks into the issue. If team B needs to be aware of every change team A makes as soon as possible, we have team B's CI build pull from team A's CI build reference library instead of the corporate reference library.

- Steve