Administración de Dependencias de terceros internos

Question

Tenemos muchas soluciones/proyectos diferentes que son administrados por diferentes equipos. Nuestra solución necesita hacer referencia a varios proyectos que posee otro equipo. No queremos agregar estas dependencias como referencias de proyectos porque no tenemos la intención de modificar ese código, solo queremos usarlo. Además, ya tenemos bastantes proyectos en nuestra solución y no queremos agregar mucho más, ya que ralentizará Visual Studio. Así que estamos construyendo estos proyectos en una solución separada y agregándolos como referencias de archivo a nuestra solución.

Mi pregunta es, ¿cómo gestionan las personas este tipo de dependencias? ¿Debo tener algún proceso automatizado para buscar cambios en esos proyectos, construirlos y verificar los dlls en nuestro control de origen, después de lo cual los tratamos como otras dependencias de terceros? ¿Hay una manera recomendada de hacer esto?

Answer 1

Una solución, aunque puede no ser necesariamente lo que está buscando, es hacer que cada subsistema dependiente realice una versión. Esta versión podría tener la forma de una instalación de MSI, o simplemente una red compartida de ensamblajes. Cuando se realiza un cambio significativo, ese equipo podría informarle, y podría ejecutar la instalación o un script para copiar los archivos.

Una vez que haya obtenido el lanzamiento, podría colocarlo en el GAC, de esa manera no tendría que preocuparse de copiarlo en las carpetas de su contenedor de proyecto.

Otra solución, suponiendo que esté utilizando un servidor de compilación o una integración continua de algún tipo, es tener un paso posterior a la compilación o etapa de proceso de los archivos. En un momento dado, los desarrolladores de los otros equipos podrían tomar los nuevos archivos, o tener un script o un archivo bat para desplegarlos localmente.

EDITAR - OTRA SOLUCIÓN Podría ser mejor preguntar por qué tiene estas dependencias? ¿Realmente los necesitas localmente cuando construyes tu parte de la aplicación? ¿Podrías burlar las dependencias en tu solución, permitiéndote codificar, construir y ejecutar pruebas unitarias? La aplicación real conectaría esto en sus entornos DEV/Test/Prod. Mantener su solución desacoplada y libre de dependencia puede ser una mejor solución para el equipo individual. Deje la integración y el acoplamiento cuando la aplicación se ejecute en una configuración real.

Answer 2

(No es un ^{completa respuesta, pero aún así:})
Cualquier entrega es mejor almacenado en un depósito de archivos/binario, en contraposición a un VCS se utiliza para gestionar las fuentes historia.

Preferimos la gestión de las entregas en un acuerdo de recompra como Nexus, y estamos utilizando maven para volver las dependencias correctas.
Incluso si esas herramientas pueden estar más orientadas a Java, Nexus puede almacenar cualquier cosa, y maven solo está allí para leer el pom.xml de cada artefacto y calcular las dependencias correctas.