Svn externals and c# assemblies - incompatible?

something that开发者_开发技巧 should be so simple in .net seems to be oh-so-hard.

I have a project called MyExtenders, containing a few simple extenders to basic types.

Many projects use MyExtenders - and so in traditional svn checkout and build approach I add MyExtenders as an svn:external with the revision locked to whichever it was last built and tested at.

Now if I have two projects both requiring MyExtenders added to the same solution it all falls in a heap. I cannot add both MyExtenders to the solution - so I have to use just one - which in the case of different revisions means re-testing the older project with it.

A diagram possibly best explains the dependencies:

SolutionA
->ProjectA
->->MyExtenders r350 (svn:externed by ProjectA)
->ProjectB
->->MyCryptography r800 (svn:externed by ProjectB)
->->->MyExtenders r800 (svn:externed by MyCryptography)

Delphi/C work with the above just fine - all references are from their own project folder.

VS insists on losing the directory structure and flattening the above to:

SolutionA
->ProjectA (refers MyExtenders)
->ProjectB (refers MyCryptography)
->MyCryptography r800 (refers MyExtenders)
->MyExtenders r350 || r800 - my choice

And me being forced to modify one of the projects to refer to a different MyExtenders, and a different revision at that.

Clearly I'm doing it all wrong.. but how do you do it right?

There really is no way around this: if you have two different projects depending on different versions of the same assembly, you are bound to have conflicts regardless of how you manage the inter-project dependencies. To see why this is, imagine that all your source conflicts could be solved somehow - now what will you do upon deployment? Which assembly version of the dependency gets loaded? Whichever it is, it will likely break the depending assembly which needs the other version.

If you have a design which requires a shared library among various subsystems, and those subsystems live in the same process (ok, technically, the same AppDomain), you need to have the same assembly version for both.

This problem goes away if you can get the depending assemblies separated by a boundary, such as a service interface or remoting channel. Then you can version the dependencies independently. Visual Studio will not like having two projects in one solution with the same name, however, so the only way around this is to copy one of the project files, rename it, and load it into the solution.