.net - sp2 - Organizar una solución de Visual Studio con "Carpetas de solución"
visual studio 2008 sp2 (10)
Debes organizar de una manera sensata. Tener una carpeta de solución por proyecto no tiene sentido.
Algo que usamos mucho es esto
-> Web (todos los proyectos web) -> Datos (cualquier proyecto relacionado con los datos) -> Prueba (Todos los proyectos de pruebas unitarias)
Cuando configura una solución de Visual Studio .NET con muchos proyectos, ¿le parece útil "Carpetas de solución"? ¿Cuáles son los inconvenientes?
Mi idea original fue que usar Solution Folders puede ser útil para organizar de manera lógica proyectos similares dentro de una solución. Sin embargo, me sorprendió saber que al crear una Carpeta de soluciones no se crea una carpeta correspondiente de Windows. Desde MSDN:
"Las carpetas de soluciones son una herramienta organizativa en el Explorador de soluciones, no se crean las carpetas correspondientes de Windows. Recomendamos que organice sus proyectos en el disco de la misma forma que los organiza en la solución".
Estoy considerando organizar la solución para que cada proyecto esté dentro de una carpeta de soluciones. ¿Es esta una buena idea?
En mi experiencia, simplemente hacen las cosas más confusas, por la razón que dice MSDN. Si hace clic derecho en una carpeta real en VS, obtiene el comando "Abrir carpeta en Windows Explorer". Si hace clic derecho en una carpeta de solución, nada. Además, tienden a desordenar rutinas que colapsan el explorador de soluciones; las cosas dentro de las carpetas de soluciones no colapsan correctamente.
Si tiene tantos proyectos en una solución que cree que necesita carpetas de solución para solucionarlos, considere si podría, en cambio, crear soluciones por separado.
Las carpetas de soluciones pueden ayudar a organizar sus proyectos. Y tienen una gran ventaja: si desea construir algunos conjuntos de proyectos, puede marcarlos, hacer clic con el botón derecho y seleccionar "Crear proyectos seleccionados". Si la organización de su carpeta de soluciones se adapta, simplemente haga clic derecho en la carpeta de la solución y seleccione "Crear".
Tenemos sln-folders para "MainApps" y "Test" (y alguna otra). Si necesita todas las aplicaciones, crea la solución completa. Pero si no quiere esperar a que se construyan los proyectos de prueba, simplemente puede hacer clic derecho y crear la carpeta "MainApps".
No sé sobre las carpetas de soluciones, pero dentro de un proyecto, puede usar carpetas para organizar los archivos fuente juntos de una manera lógica, y ESOS parecen llevar al sistema de archivos sin problemas.
No, deberías poner todo el proyecto relacionado en una sola solución. Si tiene referencias a otra solución y quiere tener acceso a su fuente, entonces agregue eso como una solución separada.
Para situaciones en las que se está desarrollando una aplicación WPF que tiene a los diseñadores accediendo a la solución en Expression Blend, las carpetas de solución se ignoran en el entorno de fusión. Por lo tanto, todos los proyectos se mostrarán en el nivel superior.
Además, cuando Blend carga la solución, se muestra un cuadro de mensaje que indica "Las carpetas de solución no son compatibles. Los proyectos anidados se cargarán normalmente". La opción "No mostrar este mensaje otra vez" puede ser verificada, pero aún así es algo molesto.
Una solución es una colección de proyectos relevantes, reunidos para cumplir algún propósito, como una aplicación. El archivo de la solución (sí, es un archivo real, no una carpeta, aunque aparece como una carpeta en VS) vale la pena echarle un vistazo al interior; solo son metadatos que describen qué contiene la solución, sobre todo sus proyectos.
Puede legítimamente utilizar los mismos proyectos en diferentes soluciones.
Por ejemplo, tenemos una aplicación WinForms, que tiene proyectos tales como:
- Objetos de negocio
- Acceso a los datos
- EnvironmentSupport
- Controles personalizados
- MainUI (en realidad no se llama así, pero eso es lo que es)
La construcción de la solución crea toda la aplicación de Windows.
Entonces también tenemos una aplicación web, en su propia solución. Pero como reutilizamos varios de nuestros proyectos, ellos también aparecen en la solución web, que tiene:
- Objetos de negocio
- Acceso a los datos
- EnvironmentSupport
- MainWebUI (de nuevo, en realidad no se llama así)
- CustomWebControls
Una vez más, la construcción de la solución crea todo el sitio web.
Nuestros proyectos aparecen en control de fuente solo una vez, y todo funciona de maravilla.
La forma en que lo hemos estructurado, una solución más o menos equivale a una aplicación, aunque esta es solo una relación suelta. También tenemos una solución de implementación para la aplicación de Windows, que tiene todos los proyectos de la aplicación WinForms, más el proyecto de instalación (que crea el .MSI). Lo mantenemos separado ya que contiene muchas cosas adicionales que lo hacen bastante grande.
HTH.
Utilizamos Carpetas de solución bastante para "asociar" proyectos dentro de una Solución. Por ejemplo, la mayoría de nuestros "proyectos" tienen 3 proyectos reales: implementación, pruebas unitarias y pruebas de integración. Ponemos los 3 en una Carpeta de Solución. También podríamos poner toda la infraestructura en uno y todos los módulos CAB en otro. Básicamente, cuando tiene una solución con más de 50 proyectos, ayuda a mantenerlos organizados para que pueda expandir solo lo que está buscando y encuentre cosas basadas en agrupaciones lógicas.
Una desventaja de usar carpetas de solución es cómo se ven en su sistema de control de versiones. Como las carpetas de solución son carpetas lógicas, no las verá en el VCS. En cambio, verá todos sus proyectos en una sola lista plana.
Esto me ha causado confusión ya que la estructura puede parecer diferente, especialmente si tiene archivos en sus carpetas de soluciones en lugar de solo proyectos.
Aquí hay una pregunta relacionada que hice hace un tiempo. Una de mis respuestas habla de algunos de los pros / contras de las carpetas de soluciones y de cómo las estoy usando actualmente.