Visual Studio: ¿Una sola solución o muchas soluciones?

Question

En este momento, este código heredado es un proyecto múltiple, cada uno en su propia solución. Cada proyecto hace referencia a otro proyecto por su compilación dll. Para ejecutar el proyecto principal, debe realizar más de 10 compilaciones individuales en el orden correcto.

Estoy tratando de explicar cómo mover todos los proyectos en una sola solución es una buena idea para solucionar todos estos problemas. ¿Cómo puedo explicar a los otros desarrolladores que esta es una mejor idea? No veo cómo no es una mejor manera de hacerlo, pero ¿o estoy equivocado?

Answer 1

estás en lo correcto y yo lo explicaría a otro desarrollador en términos de beneficios

El argumento más simple para mí es la construcción de 1 vez es mucho más rápido que la construcción de una solución 1 10 veces. Cargar cada una de las diferentes soluciones de forma individual es tedioso y lleva mucho tiempo. Visual Studio trata de mejorar tu vida, cargar soluciones 10 veces diferentes solo empeora tu vida.

poniendo Además todos los proyectos en una solución significa que usted obtiene soporte en tiempo real para muchas funciones como IntelliSense, Refactoring, encontrar todos referencias, etc ... ¿Tiene referencias de proyectos en vivo produce una mucho experiencia mejor que ir a través de DLL. La refactorización es una característica que está severamente limitada en su utilidad cuando se navega a través de DLL.

Si les preocupa el costo de reconstruir el mundo constantemente al iterar en un proyecto raíz, entonces el mejor enfoque es crear una nueva configuración de compilación que solo genere los proyectos raíz. Las soluciones admiten múltiples configuraciones de compilación y el cambio entre ellas es muy rápido (mucho más rápido que cambiar de una solución a otra).

Answer 2

Hágalo usted mismo en una copia local y luego puede mostrarles por qué es mejor.

Answer 3

En general, estoy de acuerdo con @JaredPar, pero hay algunas cosas que considerar al crear una solución masiva.

1. Rendimiento - Sí edificio puede ser menos de una tarea tediosa, pero La reconstrucción de un montón de proyectos "núcleo" que cambian con poca frecuencia desperdicia ciclos, cuando Jared dijo que se puede mitigar este con configuraciones de construcción. Además, Visual Studio tiende a ser un cerdo de recursos y el problema, según mi experiencia, se agrava a medida que crece la solución. Si tiene piezas centrales que cambian con poca frecuencia, ¿cuál es el beneficio de cargarlas todo el tiempo?

2. Refactorización - Esta es una espada de doble filo IMO. Sí, es más fácil hacer cambios de nombre, movimientos, reemplazos, etc. cuando se carga todo el código. Sin embargo, dado que es más fácil, también puede encontrarse con situaciones en las que las personas agregarán referencias a los proyectos y moverán las cosas a través de los límites del proyecto cuando, desde una perspectiva arquitectónica, ese no sea el enfoque correcto. Debido a VS hace que sea tan fácil de hacer que usted tiene que mirar hacia fuera para las personas ciegas refactorización y romper pautas arquitectónicas

P & P ha publicado una guía sobre este tema: http://msdn.microsoft.com/en-us/library/bb668953.aspx

Es un poco anticuado, y habla sobre TFS específicamente, pero algunos de los conceptos principales aún son valiosos a considerar.