¿Cómo se divide una solución de Visual Studio?

Question

Tengo una solución de Visual Studio 2008 con> 40 proyectos C# y C++/CLI que dependen uno del otro. Trabajar con esa solución es bastante lento, y generalmente solo necesito algunos proyectos a la vez. Así que decidí dividir la solución en múltiples soluciones que contienen 3-5 proyectos. También me gustaría mantener la solución "completa" en todos los proyectos (es útil para construcciones automatizadas o grandes acciones de refactorización que afectan a todos los proyectos). (Esta es la condición principal aquí. De lo contrario, dividir proyectos en soluciones es trivial, por supuesto.)

¿Hay alguna manera de hacerlo?

Mi primera idea fue crear nuevas soluciones vacías y agregar algunos de los archivos de proyecto existentes en cada una de estas soluciones. Pero si lo hago, VS ya no puede encontrar las referencias del proyecto (porque no están en la misma solución). Puedo agregar las referencias como referencias de archivos "normales". Pero si hago eso, mi solución "completa" ya no funciona, porque las dependencias están perdidas.

EDIT:

Gracias a todos por sus respuestas. Me gustaría aclarar mi pregunta un poco: mi solución contiene 44 proyectos, sin incluir los exámenes. Así que dividirlo en 2 partes no es realmente lo que tenía en mente, pensaba más en 5-8 partes. Es por eso que me gustaría mantener la solución "completa" donde VS pueda descubrir el orden de construcción correcto para una compilación completa. Mantener el orden de compilación para 8 soluciones separadas a mano (por ejemplo, en un archivo por lotes) parece propenso a errores.

También me gustaría agrupar los proyectos "lógicamente" (es decir, me gustaría tener los proyectos que generalmente se modifican juntos en una sola solución). Pero esa agrupación no siempre coincide con las dependencias. Por ejemplo, imaginar que tengo la cadena de dependencias

A is referenced by B is referenced by C is referenced by D 

e imaginar que A y D se modifican a menudo juntos, pero B y C rara vez cambian. (Obviamente, la interfaz de A que B utiliza debe permanecer inalterada para eso.) Entonces me gustaría tener A y D en una solución, B y C en otra. Pero eso solo funcionaría si pudiera tener una solución "completa" intacta que contenga A, B, C y D si quiero construir todos los proyectos desde cero. Una vez que la compilación esté completa, podría abrir mi solución A/D y editar/compilar solo esos 2 proyectos.

Pero me temo que no hay una solución elegante para mi problema. (juego de palabras no intencionado)

Answer 1

No hay una buena manera de hacerlo. Las herramientas no están construidas con eso en mente. En cambio, debes combinar tus proyectos tanto como puedas. Aunque es la misma cantidad de código, las compilaciones se ejecutarán muchas veces más rápido.

Tendrás que olvidar la idea de que se requieren proyectos separados para tener buenas abstracciones. Parece una forma muy limpia de forzar la separación. Pero no vale la pena el precio con esta cadena de herramientas. Use las características de idioma en su lugar; clases, espacios de nombres, etc.

Answer 2

Otro enfoque que quizás desee considerar es simplemente descargar los proyectos que no está utilizando, simplemente haga clic y descargue los que no está trabajando ... esto debería resultar en un dispositivo mucho más ágil Estudio visual. Mantiene muchas cosas fuera de la memoria VS.

Otra cosa que puede hacer es editar la definición de compilación y eliminar los proyectos no modificados (según cómo sean sus enlaces ... ya sabe lo que necesita/actualiza/no necesita).

Solución -> clic derecho -> Gestor de configuración de -> desmarque Build en algún proyecto que no cambian y no son necesarios cada generación por alguna otra razón. Esto acelera su construcción mediante el uso de la última versión de estos proyectos, desde donde descargan sus binarios hasta.

Nota: Todavía puede hacer clic derecho en un proyecto y compilar para actualizar su resultado y luego reconstruir la solución para obtener la última ...puede hacer esto en lugar de cambiar la configuración de compilación para incluirla.

actualización
En el espíritu de tomar la ruta de rendimiento (por ejemplo, esperar hasta que realmente VS 2010), ¿ha tomado las medidas enumeradas en algunas otras preguntas de desbordamiento de pila: Very slow compile times on Visual Studio y Visual Studio Optimizations? Estos pueden hacer una gran diferencia, y pueden llevar el rendimiento a un nivel aceptable mientras nosotros wait on VS 2010 to ship.
Unas cuantas más cosas que pueden tener un buen impacto en el rendimiento:

• I highly recommend an SSD si se trata de una opción. Son costosos, pero definitivamente valen la pena, cuantos más archivos encuentren en su solución, más pagarán. Cuando pedimos máquinas nuevas en el trabajo, todo el equipo de desarrollo se fue con SSD, la diferencia es asombrosa. Cuando se trata de una solución grande, está girando la unidad para cambiar el cabezal físico a miles de ubicaciones solo para leer los archivos ... es ahí donde ganan las SSD, el tiempo de búsqueda es efectivamente de 0 ms.
• En la misma línea, una solución gratuita es un buen drafragmenter (solo si estás en un examen físico, NO defragas un SSD) hace una gran diferencia ... si usas algo que tenga en mente el estudio visual . Recomiendo MyDefrag (freeware), ya que es un algoritmo nativo para defragging que mantiene la estructura del directorio en mente, por lo que al menos una unidad física no pasa tanto tiempo cambiando para cargar los archivos que necesita en su solución, todos están muy cerca el disco.
• Con la sugerencia de SSD anterior, tenga en cuenta que hay una gran disparidad en el rendimiento de SSD entre un disco barato y un disco rápido, investigue un poco aquí. No se preocupe por su sistema, con una utilidad gratuita such as gParted puede mover toda su unidad de SO más fácilmente, y su unidad anterior seguirá siendo una copia de seguridad ... siempre y cuando la SSD pueda ajustar los datos de su C, usted 'eres bueno.

Answer 3

Puede hacer múltiples soluciones y agregar cualquier proyecto (s) a cada solución que desee.

Los proyectos que desea construir pueden tener dependencias en otros proyectos. En este caso, debe cambiar desde el uso de una referencia de "Proyecto" (que hace referencia a cualquier otro proyecto en la solución) a utilizar una referencia de Archivo (donde hace referencia al archivo .dll de ensamblaje que el proyecto ha creado).

Así que pensemos en ellos como "bibliotecas" (compiladas una vez y luego usadas mucho) y proyectos "centrales" (que está cambiando mucho). Haga que la (s) solución (es) contengan sus proyectos de "biblioteca" y (preferiblemente) agregue un paso posterior a la compilación que copie los dll de depuración/liberación resultantes en carpetas de bibliotecas compartidas. Agregue los proyectos principales a una nueva solución. Cambie todas las referencias de la solución principal para hacer referencia a sus bibliotecas a través de las DLL binarias pre compiladas en sus carpetas compartidas (consulte la versión de lanzamiento dll para que su versión final funcione correctamente).

Si cambia una biblioteca, debe compilar la solución de la biblioteca para reconstruirla y luego usar la solución principal para reconstruir la (s) aplicación (es) que dependen de la biblioteca. (Por lo tanto, es una buena idea colocar cualquier código que se cambie con frecuencia en la solución principal en lugar de hacerlo en una biblioteca. Puede mover proyectos en una fecha posterior cuando maduren y/o hacer libraires en proyectos centrales si es necesario muy modificada por un tiempo)

una última opción, en el caso de las bibliotecas que tienen un tiempo para construir y que cambian con muy poca frecuencia, es hacerlos bibliotecas "precompilados" - comprobar los archivos dll finales en al control de código fuente , y los miembros de su equipo pueden obtener la versión más reciente y compilar contra las bibliotecas sin necesidad de obtener o construir el código fuente para ellos.(Para actualizar estas bibliotecas, debe recordar comprobar los archivos .dll binarios antes de compilarlos y luego verificarlos nuevamente después de reconstruirlos, por lo que debe sopesar las ventajas (compilaciones día a día más sencillas &) frente a las desventajas (un poco más de esfuerzo para realizar cambios en las bibliotecas, archivos binarios grandes en control de código fuente).

Answer 4

Otra opción es tener una única solución que todo lo abarca, y crear diferentes configuraciones de construcción.

en la parte superior de la window es un cuadro combinado donde puede elegir Debug o Release build configuration. Sáltelo y elija la opción "Configuration Manager ..."

En "Configuración de solución activa", despliegue el cuadro combinado y elija < Nuevo ...>. Cree una nueva configuración (por ejemplo, llamada "CoreOnly") y seleccione "Copiar configuración desde" como "Depurar". Desmarque la opción "Crear configuraciones de proyecto nuevas".

Ahora, su configuración de compilación "CoreOnly" aparecerá en la ventana. Muestra una lista de todos los proyectos. Para cualquier proyecto que no desee construir, desmarque la casilla "Crear" en la columna de la derecha. Cierra el diálogo.

Ahora, para compilar todos los proyectos, elija "Depurar" en el menú desplegable de configuración y compilar como de costumbre. Cuando todos sus proyectos se hayan creado, puede desplegarlos solo para construir los proyectos "centrales" al cambiar a la configuración CoreOnly. Siempre y cuando recuerde construir la compilación Debug (todos los proyectos) cuando edite código que no está en ninguno de los proyectos centrales, estará bien, y sus compilaciones CoreOnly serán mucho más rápidas.

El por los lados de este enfoque son que la solución puede ser muy lento para abrir (aunque en Visual Studio 2008, Visual Studio 2010 y Visual Studio 2012 esto es mucho mejor de lo que era en Visual Studio 2005, por lo que no puede tener un problema con él) y que si un proyecto no está habilitado en su configuración, no será reconstruido y entonces su compilación (o la aplicación en ejecución) puede desmoronarse - debe recordar volver a la versión normal de "compilar todo" "configuración si cree que ha realizado cambios en (o afectan) los proyectos deshabilitados.

Answer 5

Debería tener una separación de preocupaciones, especialmente al agrupar proyectos dentro de una Solución de Visual Studio. Recientemente me encontré con este problema en el trabajo donde tuve que crear un conjunto de pruebas unitarias y la prueba original creada por el desarrollador se incluyó en la solución. Al principio, pensé que O.K. Voy a poner mis pruebas aquí, b/c. Sé que funcionará y no tiene que preocuparse por obtener las dependencias correctas. Pero luego, después de que agregué como 20 proyectos de prueba para cada unidad diferente, me di cuenta de que se estaba construyendo tan increíblemente lento.

Luego decidí crear una solución para CADA conjunto de pruebas en lugar de ponerlas todas en un solo lugar. Esto también ayuda a organizar mejor tu código para que sea más fácil de encontrar. Por ejemplo, creé una carpeta 'Test> Unit> MyUnitTest' y 'Test> Integration> MyIntegrationTest'. No solo hace que sea fácil encontrar las cosas más adelante, sino que también te ayuda a acelerar tus compilaciones. Además, si hay un grupo de personas trabajando en el código a la vez, cada desarrollador podría cambiar las configuraciones y configuraciones del proyecto y no estropear las demás.

La regla general es tener solo 7 elementos o menos agrupados en un área determinada. Si tiene más de 7 elementos, entonces hay otra subcategoría que podría crear para hacerlo más abstracto y más fácil para que el cerebro humano comprenda todos los detalles complicados de un vistazo (especialmente para personas nuevas en el sistema o si vuelven al proyecto meses o incluso años después).

Answer 6

Tres años después de su pregunta, nuestro equipo sigue enfrentando el mismo problema, no el tiempo de compilación, pero el hecho de que no hay una buena manera de dividir lo que lógicamente está separado en soluciones separadas.

Terminamos construyendo nuestra propia herramienta en la forma de soldr (open source), una herramienta de compilación entre soluciones. Opcionalmente puede aprovechar nuget para administrar su código base o trabajar por su cuenta. La idea es dividir su trabajo en tantas soluciones (.sln) como tenga sentido lógicamente. En nuestro caso, tenemos uno para nuestro framework interno, y luego uno sln para cada una de nuestras bibliotecas back-end, una para cada producto, etc. Cada solución tiene un directorio "components" (similar a Nuget "packages" dir) donde almacenar los archivos de biblioteca reales (DLL, etc.) a los que la solución actual hace referencia. Estas DLL deben actualizarse a partir de una compilación nueva de la dependencia para el destino sln para ver una nueva versión.

En lugar de mano de obra manual utilizamos our aforementioned build tool. Utilizando reglas y convenciones muy simples, infiere automáticamente las dependencias entre soluciones. A continuación, puede compilar todo el grafo de dependencia correctamente (o generar un archivo MSBuild para hacerlo), en cada paso construyendo y copiando los resultados en el directorio de componentes del próximo objetivo. También hemos añadido funciones para el filtrado de lo que va a ser construido (por ejemplo, construir sólo las dependencias directas), gráficos de dependencia de impresión, la ejecución de pruebas unitarias, etc.

actualización: Para aprovechar Nuget hemos añadido soporte para generar nuspec archivos con dependencias automáticamente inferidas.

Answer 7

Tenemos más de 500 proyectos en una solución. Hay beneficios para mantener cada proyecto en una sola solución, especialmente cuando se cambia un proyecto base que afecta a todos los demás proyectos (por ejemplo, clases de ayuda).

Encontramos que la mejor manera de continuar es usar el vsFunnel extension para Visual Studio. Tiene la capacidad de cargar una solución SIN los proyectos. Los proyectos todavía se enumeran en la solución, pero no se cargan hasta que sea necesario. Cuando un proyecto se abre a través de la interfaz de usuario, se carga a pedido.

El verdadero truco es habilitar "Load Dependencies" (Cargar dependencias) desde la interfaz de usuario de vsFunnel. Al abrir un proyecto, carga todos los proyectos dependientes, etc. lo que hace que trabajar en un proyecto objetivo sea mucho más fácil.

Por ejemplo, en nuestros más de 500 proyectos, a menudo nos enfocamos en una sola aplicación, y podría tener 20 proyectos dependientes. Solo aquellos están cargados, NO los 500+ completos.

Sugerencia: Elija Cargar dependencias Y Cargar ninguna - luego, cuando abre su proyecto de destino en la interfaz de usuario, se cargan todos los proyectos relacionados.

Esto ha resultado ser un enorme ahorro de tiempo (¡más un disco SSD!)

Answer 8

Además de lo mencionado aquí soldr y Funnel Puedo recomendarlo usando Solution Load Manager. Sí, SSD ayuda, pero VS tiene errores: se bloquea, deja de responder y surgen otros problemas cuando se trabaja en más de 100 proyectos. Mantenerlo todo junto para la refactorización, la reconstrucción y la depuración importantes es imprescindible, pero trabajar en subconjuntos más pequeños de proyectos a diario mejorará en gran medida el rendimiento y la satisfacción.

ps. Me gustaría saber si alguien ha realizado la comparación Funnel vs. Solution Load Manger.