Soluciones de estudio visual con un gran número de proyectos

Question

Veo a los desarrolladores desarrollar con frecuencia contra una solución que contiene todos los proyectos (27) en un sistema. Esto plantea problemas de duración de compilación (5 minutos), rendimiento de Visual Studio (como latencia intellisense), además de que no obliga al desarrollador a pensar en las dependencias del proyecto (hasta que obtenga un problema de referencia circular).

¿Es una buena idea descomponer una solución como esta en soluciones más pequeñas que sean compilables y verificables independientemente de la solución "madre"? ¿Hay algún riesgo potencial con este enfoque?

Answer 1

Permítanme reiterar sus preguntas:

¿Es una buena idea para romper una solución como esta en soluciones más pequeñas

El MSDN article you linked hace una declaración muy clara:

Importante A menos que tenga muy buenas razones para utilizar un modelo de soluciones múltiples, debe evitar esto y adoptar eith Es un modelo de solución único, o en sistemas más grandes, un modelo de solución única con particiones. Es más fácil trabajar con ellos y ofrecen una serie de ventajas significativas sobre el modelo de soluciones múltiples, que se analizan en las siguientes secciones.

Por otra parte, el artículo recomienda que siempre tienen un solo archivo de solución "maestro" en su proceso de construcción.

¿Hay algún riesgo potencial con este enfoque?

Usted tendrá que hacer frente a las siguientes cuestiones (que en realidad puede ser muy difícil de hacer, misma fuente que la cita anterior):

El modelo de solución multi sufre de las siguientes desventajas :

• usted está obligado a utilizar las referencias de archivos cuando se necesita hacer referencia a una asamblea generada por un proyecto en una solución separada. Estos (a diferencia de las referencias de proyecto ) no configuran automáticamente las dependencias de compilación . Esto significa que debe abordar el problema del orden de generación de la solución dentro del script de compilación del sistema. Si bien esto se puede gestionar, agrega complejidad adicional al proceso de compilación.
• También se le obliga a hacer referencia a una compilación de configuración específica de una DLL (por ejemplo, la versión Release o Debug ). Las referencias de proyecto administran automáticamente esto y hacen referencia a la configuración actualmente activa en Visual Studio .NET.
• Cuando trabaje con soluciones únicas, puede obtener el código más reciente (quizás en otros proyectos) desarrollado por otros miembros del equipo para realizar pruebas de integración local . Puede confirmar que nada se rompe antes de comprobar su código de nuevo en VSS listo para la siguiente compilación del sistema . En un sistema de solución múltiple esto es mucho más difícil de hacer, porque puede probar su solución frente a otras soluciones solo mediante el uso de compilación de los resultados del sistema anterior compilación.

Answer 2

Sin duda tiene sus ventajas y desventajas; de todos modos, dividir una solución en múltiples proyectos le ayuda a encontrar lo que busca fácilmente, es decir, si está buscando información sobre cómo informar, vaya al proyecto de informes. también permite que los equipos grandes para dividir el trabajo de tal manera que nadie haga algo para romper el código de alguien mas ...

Esto plantea problemas de duración acumulación

puede evitar que al único edificio los proyectos que usted modificó y dejar que el servidor de CI haga toda la compilación

Answer 3

Tenemos una solución de ~ 250 proyectos.

Está bien, después de instalar un parche para Visual Studio 2005 para manejar soluciones extremadamente grandes [TODO add link].

También tenemos soluciones más pequeñas para equipos con selección de sus proyectos favoritos, pero cada proyecto agregado también debe agregarse a la solución maestra, y muchas personas prefieren trabajar con él.

Hemos reprogramado el acceso directo F7 (compilación) para compilar el proyecto de inicio en lugar de la solución completa. Eso es mejor.

Las carpetas de soluciones parecen resolver el problema de encontrar las cosas bien.

Las dependencias solo se agregan a proyectos de nivel superior (EXEs y DLL) porque, cuando tiene bibliotecas estáticas, si A es dependencia de B y B es dependencia de C, A no es necesario que dependa de C (para hacer que las cosas compilar y ejecutar correctamente) y de esta manera, las dependencias circullar están bien para el compilador (aunque muy malo para la salud mental).

Admitir tener menos bibliotecas, incluso hasta el punto de tener una biblioteca llamada "biblioteca". No veo una ventaja significativa de la optimización de la huella de memoria de proceso al traer "solo lo que necesita", y el vinculador debería hacerlo de todos modos en el nivel de archivo de objeto.

Answer 4

La única vez que realmente veo la necesidad de múltiples soluciones es el aislamiento funcional. Las bibliotecas necesarias para un servicio de Windows pueden ser diferentes a las de un sitio web. Cada solución debe optimizarse para producir un solo ejecutable o sitio web, IMO. Mejora la separación de la preocupación y hace que sea fácil reconstruir una pieza funcional de la aplicación sin construir todo lo demás junto con ella.

Answer 5

El rendimiento de Intellisense debería ser bastante mejor en VS2010 en comparación con VS2008. Además, ¿por qué necesitarías reconstruir toda la solución todo el tiempo? Eso solo ocurrirá si cambia algo cerca de la raíz del árbol de dependencias, de lo contrario, solo construirá el proyecto en el que está trabajando actualmente.

Siempre me ha parecido útil tener todo en una sola solución porque podía navegar fácilmente por todo el código base.

Answer 6

Visual Studio 2010 Ultimate dispone de varias herramientas para ayudarle a entender y manejar mejor las dependencias de código existente:

• gráficos de dependencia y Arquitectura Explorador
• diagramas de secuencia
• diagramas de capa y validación

Para obtener más información, consulte Exploring Existing Code. El Visualization and Modeling Feature Pack proporciona soporte de gráficos de dependencia para C++ y código C.

Answer 7

¿Es una buena idea descomponer una solución como esta en soluciones más pequeñas que son compilables y comprobables independientemente de la solución "madre"? ¿Hay algún riesgo potencial con este enfoque?

Sí, es una buena idea porque:

• Usted no quiere VS para reducir la velocidad en una solución con docenas de proyectos VS.
• Puede ser interesante centrarse solo en una parte del código, esto refuerza la noción de localidad de código que es algo bueno.

Pero lo primero a lo que se debe luchar es a tener el menor número posible de proyectos/ensamblajes de VS. Mi compañía publicó dos free two white books que explican los pro/contras de usar ensambles/proyectos VS/espacios de nombres para particionar una gran base de código.

• Partitioning code base through .NET assemblies and Visual Studio projects (8 páginas)
• Defining .NET Components with Namespaces (7 páginas)

El primer blanco-libro explica también que VS es bastante lento cuando se trabaja con una solución con docenas de proyectos, y muestra trucos acerca de cómo remediar esta lentitud