Svn Externals y c # assemblies – incompatibles?

algo que debería ser tan simple en .net parece ser tan difícil.

Tengo un proyecto llamado MyExtenders, que contiene algunos extendedores simples para types básicos.

Muchos proyectos usan MyExtenders, por lo tanto, en el process de compilation y compilation de svn tradicional, agrego MyExtenders como svn: external con la revisión bloqueada en la que fue creada y probada por última vez.

Ahora, si tengo dos proyectos que requieren que MyExtenders se agreguen a la misma solución, todo cae en un montón. No puedo agregar MyExtenders a la solución, así que tengo que usar solo una, que en el caso de las diferentes revisiones significa volver a probar el proyecto anterior con la misma.

Un diagtwig posiblemente mejor explica las dependencies:

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

Delphi / C funciona con lo anterior muy bien – todas las references son de su propia carpeta de proyectos.

VS insiste en perder la estructura del directory y aplanar lo anterior para:

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

Y me veo obligado a modificar uno de los proyectos para referirme a un MyExtenders diferente, y una revisión diferente.

Claramente lo estoy haciendo todo mal … pero ¿cómo lo haces bien?

Realmente no hay forma de evitar esto: si tiene dos proyectos diferentes que dependen de diferentes versiones del mismo ensamblado, es probable que tenga conflictos independientemente de cómo administre las dependencies entre proyectos. Para ver por qué ocurre esto, imagine que todos sus conflictos de origen podrían resolverse de alguna manera: ¿qué hará en el deployment? ¿Qué versión de ensamblaje de la dependencia se carga? Cualquiera que sea, probablemente romperá el ensamblaje dependiente que necesita la otra versión.

Si tiene un layout que requiere una biblioteca compartida entre varios subsistemas, y esos subsistemas viven en el mismo process (vale, técnicamente, el mismo dominio de aplicación), necesita tener la misma versión de ensamblaje para ambos.

Este problema desaparece si puede get los ensamblajes dependientes separados por un límite, como una interfaz de service o un canal remoto. Entonces puede versionar las dependencies de forma independiente. No obstante, a Visual Studio no le agrada tener dos proyectos en una solución con el mismo nombre, por lo que la única forma de evitar esto es copyr uno de los files del proyecto, cambiarle el nombre y cargarlo en la solución.