TFSBuild/MSBuild y referencia de proyecto vs referencia de archivo
projects-and-solutions project-reference (2)
¿Cuál es la forma correcta de dividir sus soluciones?
Consulte este capítulo de la guía TFS del equipo Patterns & Practices:
Capítulo 3 - Estructuración de proyectos y soluciones en el control de código fuente
Preste especial atención a esta nota del escenario "Solución particionada" (que creo que en realidad está tratando de implementar):
A diferencia de las versiones anteriores de Visual Studio, Visual Studio 2005 depende de MSBuild. Ahora es posible crear estructuras de solución que no incluyan todos los proyectos referenciados y que sigan construyendo sin errores. Siempre que la solución maestra se haya creado primero, generando la salida binaria de cada proyecto, MSBuild puede seguir las referencias del proyecto fuera de los límites de su solución y construir con éxito. Esto solo funciona si usa referencias de proyectos, no referencias de archivos. Puede crear soluciones creadas de esta manera desde la línea de comandos de compilación de Visual Studio y desde el IDE, pero no con Team Build de manera predeterminada. Para construir exitosamente con Team Build, use la solución maestra que incluye todos los proyectos y dependencias.
Tenemos una gran solución de VS que utiliza referencias de proyectos que está compilada por TFS Build así:
Solution
- Project 1
- Project 2
- Project ...
- Project N
Debido a que la solución es demasiado grande, tenemos varias soluciones más pequeñas que usamos día a día:
SubSolution
- Project 1
- Project 19
El problema es que los desarrolladores que trabajan en SubSolution descubren que no está compilando porque no se encontraron las referencias del proyecto, por lo que cambian los proyectos para usar referencias de archivos.
Esto luego rompe la compilación TFS que no puede encontrar estas referencias de archivos porque todavía no se han creado (aunque los proyectos están en la misma solución). ¿Hay alguna forma de evitar este tira y afloja entre los dos tipos de referencias? ¿Cuál es la forma correcta de dividir sus soluciones?
Independientemente de cómo organice su compilación, los desarrolladores deben comprender cómo funcionan las referencias , y tener en cuenta cuando realizan cambios en las referencias que no deben verificar esos cambios a menos que tengan la intención de hacer un cambio en el proceso de compilación .
Sobre el tema de organizar sus construcciones, como dice Dmytrol, las referencias de proyectos deberían funcionar entre soluciones (siempre y cuando el objetivo ya esté construido, sin embargo, ese también es el caso para las referencias de archivos).
Mi consejo sería agrupar sus proyectos en pequeñas soluciones viables y usar referencias de proyectos dentro de esas soluciones. Su archivo / compilación de solución principal también puede usar referencias de proyecto; sin embargo, si encuentra referencias de proyecto entre las más pequeñas demasiado difíciles de mantener, puede usar referencias de archivos y controlar el orden de compilación a través de dependencias de proyectos o el orden de compilación del proyecto (accesible en Visual Studio haciendo clic derecho en un proyecto en su solución).