In reflecting on my previous post regarding shared libraries in VSS vs CVS I realized that the end of the post got to the real meat of the matter. Turns out we are using a feature of VSS to help us organize our shared libraries, however, shared libraries really have very little to do with version control (except for released versions of course).

So I did a little more research and found the Team Development articles on MSDN, specifically the one on Managing Dependencies. Here is their main recommendation:

Project references are the main reason you should adopt a single solution or partitioned single solution model wherever possible.

In the Single and Partitioned Solution Systems section:

Use project references wherever possible and aim to minimize the use of file references.

These recommendations are a little simplistic. Surely Microsoft doesn't have a single solution for the entire .NET framework! And they are only building a single product.

Further on they propose an alternative that sounds promising - use a build server and place the shared libraries on a file share. Additionally you can copy the shared libraries locally from time to time to support disconnected development and developer control over when libraries are updated.

This sounds like it will work well as long as you have a build server and all developers map the shared library share to the same drive letter. In fact using a mapped drive letter allows a lot of flexibility in that just by changing the drive letter mapping you can point to the release version, debug version or the local version of the shared libraries since VS.NET stores the absolute path to shared libraries in the project file (in the HintPath attribute).

Other articles:

• William Bartholomew Organising Visual Studio .NET Solutions
• Jeff Gonzalez Solution and Project Organization
• Roy Osherove How to: Creating project groups under a single solution
• Robert W. McLaws Developing Components: Code organization, a technique reexamination and modification