What to do with project dependencies?

Many development teams hit the problem that they have dependencies on libraries that they do not want to have as part of their solutions. If these dependencies are open source projects then there are options using technologies like NuGet or OpenWrap. However, in many cases the dependency is to an internal project, such as the company standard logging library, which it is never going to put up into a centralised repository. So normally you end up with either:

1. Adding the project for the shared assembly to the solution and rebuilding with the solution, probably via some branching model in source control to allow fixes to be merged between projects.
2. Adding the assembly from a known location (maybe under source control)  that the team responsible for then shared library publish the current version to.

Both solutions can work, but they both have their pros and cons.

A different and interesting approach has been proposed in Sven Hubert’s post “Extended Dependency Management with Team Foundation Server” on http://www.TFSBlog.de. He suggests using a custom MSBuild task and .Targets files that allows you to cause an external project to be rebuild from source control (addressing option 1 without the need to add the actual VS project to the solutions) or to pick the built assemblies from the a given Team Build (addressing option 2).

If this problem is one you have come across this post makes for interesting reading.