CAB/SCSF application and DLL/Project references

At my current place of work we're developing a new uber client application using the CAB/SCSF technologies. We've broken the mold a little as we're developing modules in solutions separate to the main Shell. There are numerous reasons for this, one of them that we've got 3 development teams in 3 different locations.

Now the official line from Microsoft is to use Project References in such situations, see the following MSDN article which is a little dated as it was published in 2002.

Now my big criticism with the Project Reference approach is that in the CAB you may well end up with modules depending on other modules, which means that you have to have all those modules in your solution. Then you have to add in the dependencies for the modules you've just added and before you know it, you've gone to the one big solution approach for each of you module solutions and the entire things becomes a pain to maintain. Just some of the bad points I can see for this scenario:

1. Versioning - Everytime you build your module you rebuild the modules your dependent on. If two modules depend on the same module which version do you deploy?
2. Building - Which version of a DLL do you take if it's build by X solutions?
3. Loading Times - I've seen some solutions with 10 or more projects in that can take 10 to 15 mins to load, is this really acceptable to Developers that just want to nip and have a quick look or do a quick fix on the code?
4. Debugging - This method will let you hit F5 and just debug straight into your app, but you're then stating that all modules will have configuration that Developer friendly.

Now the theory we're using is to have a static location to which all solutions copy their DLLs, PDBs and any other relevant files to a location on a directory hierarchy. Other solutions then reference the DLLs from the subst drive without the need of Project References. In order to get the relevant files (DLLs, PDBs and other files) onto the mapped location we use the Post Build Event to copy them, as this is configuration agnostic. The inclusion of the PDb files allows intellisense and navigation when referencing class in other DLLs.

This does mean that the developers all share a common location, in our case we use a mapped drive via the subst command that is run when the Dev logs in.

The mapped location is used to conatin all of the library files that the application uses, so things like Ent Lib, CAB and 3rd Party Controls. Then additional root nodes are added for any applications that use this structure.

One of the nicest aspects of this approach is that when a daily build/CI build is performed it creates the structure for the mapped location. A dev then coming to do the next piece of work can copy the structure to his mapped location picking up all the latest changes without the need of a get from source control and compiling.

So far I've used this at two companies both using CAB based application, and it has worked very well. I'll post shortly on how to debug these applications via the F5 button, instead of attaching to the applications process.