Recientemente en el trabajo nos encontramos con un problema en el que etiquetamos / ramificamos un proyecto y tuvimos algunos problemas de compilación debido a las referencias dll / project que apuntaban a la antigua estructura de carpetas.
Creamos una carpeta 'bin externo' para cada uno de los proyectos y copiamos los dll referenciados a estas carpetas. ¿Es esta la mejor manera o hay un estándar específico de la industria para manejar esto?
Respuestas:
Yo diría que nuget es la mejor manera de manejar las dependencias.
nuget puede administrar versiones Y descargar automáticamente las dependencias de su servidor nuget local .
Es bastante fácil crear / configurar un servidor local. Simplemente cree un nuevo proyecto ASP.NET vacío e instale el nuget-serverpaquete nuget (usando nuget;).
Eso también significa que no tendrá que verificar todas las dependencias y / o administrar sus versiones usando TFS.
En realidad no es así: Microsoft dice que la mejor manera de manejar las referencias es construir su proyecto en una gran solución. Sí, lo sé, realmente lo dicen en serio también.
El equipo de patrones y prácticas ha reunido sus mejores prácticas con respecto a TFS, pero se aplica a las compilaciones generales. Hay 3 tipos de configuración de la solución, la "1 gran solución", un enfoque particionado que se parece mucho a la forma en que la mayoría de la gente solía administrar las compilaciones construyendo a su vez y copiando artefactos en un directorio común (que no es ayudado por .NET no tener una ruta de referencia 'incluir' o 'biblioteca' en todo el servidor), y una configuración de Solución Múltiple que es una versión más compleja de la Particionada.
Ellos dicen
In general you should:
Use a single solution strategy unless the resulting solution is too large to load into Visual Studio.
Use multiple solutions to create specific views on sub-systems of your application.
Use multiple solutions to reduce the time it takes to load a solution and to reduce build time for developers.
Para TFS, recomiendan bifurcar cualquier proyecto externo dentro de su proyecto, en lugar de confiar en el mapeo del espacio de trabajo que es más similar a los externos de Subversion. Personalmente, creo que su consejo no es la mejor práctica, pero supongo que están tratando de minimizar los problemas de compilación que obtendrás al usar referencias.
He tenido problemas con las compilaciones de .NET que intentan atajar el sistema compilando solo lo que se necesita, una compilación nocturna que hace todo, y copiar cada nuevo ensamblado en un directorio fue la mejor manera para que todos se mantuvieran sincronizados, especialmente los probadores. Tenga en cuenta que esto realmente solo se aplica a las aplicaciones .NET, las de C ++ tienden a funcionar porque no tienen ensamblados versionados o aspectos similares que pueden causar problemas al llamar a los componentes. Este enfoque funciona bien, pero no siempre se puede suponer que las construcciones parciales están bien, vapear todo y reconstruir es lo más seguro.
Esto depende de cómo está estructurada su solución y cuáles son sus capacidades de software de control de versiones. Anteriormente, solíamos mantener un proyecto no construido / omitido en nuestras soluciones que contenía documentación y una carpeta específicamente para cualquier biblioteca referenciada por terceros. Como formaba parte de la solución, se podía hacer referencia a la ruta a estos archivos utilizando la ruta relativa. Después de mudarnos a TFS 2010, nos deshicimos de este proyecto y simplemente agregamos un directorio de "Soporte" en la carpeta de esa solución en el proyecto del equipo paralelo a nuestras sucursales principales. En cualquier caso, la versión de control de origen de la biblioteca termina en el mismo lugar relativamente independientemente de cómo los desarrolladores hayan configurado sus máquinas.
Al utilizar subversion para el control de versiones, puede utilizar la propiedad "externa" para este propósito. Esto le permite mantener una copia local de una DLL compartida en una ruta relativa cercana a su proyecto actual. Eso facilita hacer referencia a esa DLL mediante una ruta de archivo relativa que no cambia, incluso cuando cambia el directorio principal de su proyecto a una carpeta diferente. Los externos también le permiten definir qué versión o revisión específica incluir.