¿Debe contener un proyecto de Visual Studio en más de una solución?

Question

Nota: Esto es para una tienda que funciona en C++, C++/CLI y C# con algunos productos entregados como una combinación de los tres.

Actualmente, tenemos la regla de que un proyecto debe tener una solución que solo contenga una. La regla se instaló originalmente porque el complemento de control de código fuente para Visual Studio no pudo hacer frente a los proyectos que estaban contenidos en varias soluciones, siempre intentando cambiar los enlaces de control de origen cuando se cambia de una solución a otra.

Por otros motivos, vamos a dejar de usar el plugin de control de fuente (sin descartar el control de fuente, solo el complemento de muerte cerebral). Se vuelve a abrir la cuestión de si continuar o no la política de restringir proyectos para que estén contenidos en una sola solución.

Tenemos un buen código en bibliotecas, archivos DLL y ensamblajes que son consumidos por múltiples productos entregables, y actualmente lo controlamos con un sistema de administración de dependencias entre soluciones donde si uno está trabajando en la solución para un producto final, es una cuestión simple solicitar una compilación de las soluciones de dependencia, que inicia otras instancias de Visual Studio para compilarlas. El sistema funciona, pero tiene los siguientes inconvenientes:

• las soluciones para los proyectos comunes son a menudo demasiado grasa, que contiene un par de proyectos que necesita el producto que se está desarrollando actualmente y por lo general mucho más que no son necesarios para la trabajo de desarrollo a mano. Simplemente han sido agrupados en una especie de solución integral que cubre proyectos que están vagamente relacionados. Esto da como resultado tiempos de compilación extendidos debido a la compilación de código innecesario.
• Donde hemos tratado de resolver las soluciones de grasa anteriores, a menudo nos queda una solución demasiado delgada que contiene solo un proyecto. Cada uno de estos requiere una configuración adicional en el sistema de administración de dependencias entre soluciones. Esto también puede aumentar los tiempos de compilación a medida que se activan varias instancias de Visual Studio.

Estoy considerando revisar la política para permitir que un proyecto utilizado en múltiples productos entregables esté contenido en más de una solución. Podríamos eliminar la administración de la dependencia entre soluciones y reducir drásticamente la cantidad de soluciones (hasta una por producto). Me preocupa la cantidad de trabajo que llevará a cabo esta reorganización y si valdrá la pena o no. Me temo que ni siquiera podré detectar los beneficios potenciales hasta que el equipo haya estado trabajando con esto por un tiempo. También preveo un par de problemas potenciales que son las verdaderas preguntas aquí.

• ¿Existe una gran cantidad de proyectos en una sola solución que planteen problemas de estabilidad en Visual Studio 2005 (nuestra plataforma de desarrollo actual)? ¿Mejora en VS 2008 o VS 2010?
• Si un proyecto está contenido en más de una solución, ¿cómo se pueden gestionar los efectos en las múltiples soluciones si las configuraciones del proyecto se modifican (como agregar una nueva configuración)?

Para cualquiera que ya trabaje en un entorno con una solución por producto entregable, con componentes comunes como proyectos contenidos en múltiples soluciones: ¿Ha encontrado algún inconveniente importante en dicha configuración?

Answer 1

No, utilice tantas soluciones como sea conveniente.

Por ejemplo, tenemos una gran solución que genera alrededor de 53 proyectos.Incluye un instalador y un desinstalador para que nuestro servidor de compilación pueda construirlos convenientemente, pero si quiero trabajar en esas aplicaciones, las cargo en sus propias soluciones (1 proyecto cada una), en lugar de perder todo ese tiempo cargando otras 69 proyectos innecesarios. No tienen ninguna dependencia en los otros proyectos, así que no hay ningún problema haciéndolo de esta manera (de hecho, es mucho más eficiente a medida que la solución se carga y construye mucho más rápido)

La única salvedad de las soluciones múltiples es que debe tener cuidado en caso de que no genere una dependencia (por ejemplo, si no construye una biblioteca, entonces debe tener cuidado de que se construya cada vez que cambie el código fuente, porque no se creará). ya se construirá de forma automática para usted)

edición

para responder a la última parte de su pregunta (debido a que toma la cuestión de distancia, mientras you'r ¡editando la respuesta!), el único problema con las soluciones en VS2005 es que es muy lento con muchos proyectos en ellas. VS2008 es mucho más rápido al cargar una solución grande, pero el principal problema es que cuantos más proyectos hay en una solución, más tiempo lleva construir (incluso si se está salteando proyectos que no necesitan ser construidos) , tarda mucho tiempo)

Si agrega una nueva configuración de solución, simplemente haga una solución súper (o simplemente conserve la existente) y luego realice los cambios necesarios para que se apliquen a todos los objetos en una ida. Aún tendrá que agregar esa nueva configuración a cualquier solución por separado que desee usar, pero si son soluciones de un solo proyecto, puede simplemente eliminarlas, cargar el .csproj y se reconstruirá automáticamente con todas las configuraciones en eso. Y agregar nuevas configuraciones probablemente no va a suceder muy a menudo.

Answer 2

Yo también trabajo en un entorno que tiene muchos proyectos comunes que se utilizan en varios entregables. Nuestra política ha sido una solución por aplicación entregable. Entonces, un proyecto común puede incluirse en varias soluciones. Esto ha funcionado bien para nosotros. Los proyectos comunes, aunque se encuentran en soluciones separadas, se asignan a las mismas ubicaciones de repositorio de código fuente. Entonces, si se cambia el código común, todas las aplicaciones que lo contienen se verán afectadas (nuestro sistema de integración continua) sirve para verificar que otras aplicaciones no se rompan como resultado del cambio al código común.

Cuantos más proyectos tiene en una solución de VS, más tiempo lleva cargar y simplemente suena complicado tener que administrar diferentes configuraciones y dependencias en una sola solución.

Answer 3

Los principales problemas con los que tienen un proyecto en varias soluciones son:

• Si se hace un cambio en el proyecto, que puede causar un error de compilación en otra solución en la que se utiliza.
• Las soluciones deben ser constantemente actualizados para mantenerse al día con los cambios en los proyectos comunes

El beneficio de tener un proyecto en cada solución que se utiliza es:

• Es más fácil depurar cuando puede seguir el problema hecho al código fuente.

Otra forma de hacerlo sería hacer que cada solución utilice el dll de los proyectos comunes que requieren. Luego, cada solución puede decidir cuándo quieren cambiar qué versión usan.

La cantidad de proyectos en una solución no es un problema importante. Pero hará que la solución sea más lenta de cargar y construir. Tenemos soluciones de más de 50 proyectos.

Answer 4

Tenemos una "solución maestra" que contiene más de 100 proyectos. Esto llevó una eternidad cargar en VS.2005 hasta que Microsoft lanzó las correcciones de Intellisense descritas en here.

Nuestro procedimiento de compilación automático de "integración continua" siempre crea la solución maestra. Para el desarrollo, divido la "solución maestra" en soluciones más pequeñas que contienen un subconjunto de proyectos relacionados. Mantener esta estructura lleva algún tiempo cuando se agregan nuevos proyectos, pero bien vale la pena.

El único problema que he descubierto con proyectos en múltiples soluciones se evita usando $ (ProjectDir) en lugar de $ (SolutionDir) en reglas de compilación, ya que este último depende de cómo se carga el proyecto.

Answer 5

Tools for SLN file (Visual Studio Solution file) contiene una herramienta que:

hacen posible crear filtros para un archivo de GLC. La forma en que funciona es que cuando se abre el archivo de filtro, se crea una solución temporal dinámicamente. El archivo de solución creado solo contiene los proyectos que se especifican en el filtro y todas las dependencias de esos proyectos . Esto permite tener una mega-solución que contiene todos los proyectos necesarios para construir el sistema completo, pero todavía tiene la posibilidad de trabajar eficientemente en un subconjunto del sistema.

Esto elimina una gran parte del costo de mantener archivos de solución de subconjuntos para una mayor velocidad de desarrollo.

Sin embargo, necesita preguntarle a usted mismo si tiene más archivos de proyectos que los necesarios, ya que la combinación de archivos de proyecto puede acelerar las compilaciones y la carga de las soluciones.

Answer 6

Ahora existe una extensión gratuita de Visual Studio, "Funnel", que resuelve este problema cargando subconjuntos predefinidos de la solución. El enlace es para VS2012-VS2015; también hay una versión VS2010 a la que se hace referencia en la página de inicio de la extensión.

Puede configurar múltiples perfiles (es decir, combinaciones de proyectos). Estos se almacenan en un archivo paralelo solution.sln.vsext y ese archivo se puede confirmar y compartir con su equipo. Si bien VS2015 ha mejorado mucho en el manejo de soluciones de proyectos de más de 100 C/C++/C#, me parece particularmente útil para excluir proyectos de archivos MAKE que se crean cada vez que se construye la solución.