we're trying to sort out some conventions for handling dependencies with code checked into svn. the previous method was basically a free for all, meaning projects couldn't be checked out and built without fiddling with references (most projects are C#).
we're fixing this one step at a time, and are now checking in binaries to a separate svn repository. the builds are distinguished by the svn revision number they correspond to, so you might have a path like svnrelease/libraryA/r1000/libraryA.dll. one thing that came up is a scenario like so: library A depends on library B, project P depends on library A, but also directly references library B. what if library A refers to revision 1000 of B, but project P's direct reference is to revision 2000?
I suggested including the revision number in the DLL file names when they are checked into the releases svn repo, so multiple versions can co-exist. a co-worker suggested that VS2k8 might be able to automatically handle this. so if in the library A project, you set it to be version 1.8, VS names the output "libraryA_1_8.dll", and in project P you can have a reference to "$(release)\libraryA\$(version)" which it can resolve. I couldn't find any information on how to do this. is this possible? and if not, is my method of including the version name in the DLL binary file reasonable?
(I know the scenario suggests refactoring code might be necessary, but I'm looking for a shorter-term solution as we sort stuff out. using the GAC is also possible, but for now we want to stick with distributing the DLLs with each app.)