Mantenimiento de las referencias de ensamblado .NET comunes a múltiples proyectos

Question

Mis colegas y yo nos hemos estado preguntando la mejor manera de hacerlo por bastante tiempo: ¿cuál es una buena/estándar manera de mantener ensamblados .NET a los que se hace referencia en múltiples proyectos? Voy a elaborar un poco:

Digamos que tiene proyectos A, B y C. Podrían estar en la misma solución o en soluciones diferentes, realmente no importa. También tiene proyectos D y E que generan DLL para A/B/C como referencia. Por si fuera poco, lanzaremos un ensamblado F de terceros, para el cual solo tenemos el archivo DLL. ¿Dónde es un buen lugar para poner los conjuntos de D y E, además del archivo de F, de manera que el mayor número posible de las siguientes cosas ocurra:

• cambios a D y/o E no tienen que ser refrescado/cambiado manualmente en los proyectos A, B o C;
• Los proyectos A, B y C se pueden descargar a una nueva máquina a través del control de fuente y compilar con la menor cantidad de molestias; y
• Las salidas DLL para D y E, así como el archivo para F, están más o menos ubicadas centralmente.

Probablemente estoy pidiendo demasiado, pero ¿hay alguna manera conocida de lograr la mayoría de/todo esto? Nos ha estado desconcertando por bastante tiempo aquí.

Answer 1

Una solución (probablemente no óptima) es utilizar Maven para su gestión de dependencias.

ver este tutorial: Using Maven to manage .NET projects

Answer 2

El siguiente debe hacer el truco que pienso:

1) Tener una carpeta de destino donde el archivo DLL de terceros estaría presente.
2) Agregue también una secuencia de comandos posterior a la compilación para copiar los conjuntos D.dll y E.dll en la carpeta de versiones en la compilación correcta.
3) Los proyectos A, B y C harían referencia a D.dll y E.dll desde las carpetas de publicación.

Tampoco tiene sentido agregar D.dll y E.dll de la carpeta de lanzamiento al control de fuente. El mecanismo de construcción debería ser automáticamente capaz de manejar esto.