views:

242

answers:

4

I have several solutions, each containing multiple projects, that all need to reference a single assembly, say, lib.dll.

This contains common classes and functionality which needs to be accessed between all the solutions; and I can't bring all the projects into one solution as my manager wants to be able to use different versions of lib.dll between different solutions. I am also stuck on VSS and 2005 for the moment (sympathy votes?).

Currently, I'm having to redo references in all the projects in the solution manually; what I really want to be able to do is to have everything in one place, but obviously the GAC is out for this.

Is there any way for me have, say, a dummy project which can be referenced by all the other projects in a particular solution which, when referenced, will provide lib.dll?

Am I barking up the wrong tree here?

A: 

Even if you created a dummy project that referenced lib.dll (say project.dll), you'd still have to add a reference to that dll in all your other projects in the solution, so you'd be in the same situation, just with a different assembly.

Another note, if there are going to be different versions for lib.dll in the future and different projects would reference different versions for that dll, then you wouldn't even want to do what you're describing, because you would only be referencing one version of the dll, which would be incorrect, anyway.

What I usually do to consolidate frameworks or libraries is keep them in a common folder and reference them from there (like a References folder or something). I also have my team mimic the same folder structure. We have that checked into our repository that way and everything references well. If we change need to change the dll then we just check out the file, overwrite it, check it back in, and rebuild the solution.

Joseph
I have to apologise - I actually meant different versions between solutions. Having a reference to the project would mean I only have to update the lib.dll in one place, and the build process would take care of importing the new version for me.A reference folder won't work, as I might need different versions between different solutions.
Khanzor
A: 

The GAC should still work. You can have multiple versions of the same DLL in the GAC.

David
+1  A: 

The project files are just XML documents, so parsing in a script (IronPython is a good choice here), checking if there is a reference, and inserting or updating as required should be a comparatively trivial matter to achieve.

Steve Gilham
I have done exactly this sort of thing. I created tools that could do massive edits of the project files, and of the .user.csproj files. I could not only inject references, I could also update the Reference Paths to point to a particular version of the assembly, or to point to one on a share. It wasn't too tough, building it up bit by bit.
John Saunders
A: 

First, pick a known location the DLL can be deployed to within your source tree. Add a custom build step to the shared library to copy the build result to that known directory (using relative paths). Then, when add references to the shared library, reference it at that known location (verify the hintpath of the reference uses relative paths in the vcproj file).

I use relative paths so the share location is in the source tree that goes into source control... if someone picks up the same tree from source control it works as expected. As an alternative, you might have an environment variable per machine that points to the share path. This alternative means multiple copies of the source tree on the same machine could muck with each other, but the solutions then don't have to be located in a fixed way relative to each other. That share could also be on a network path, but then if other developers build their changes will overwrite each others.

Frank Schwieterman