c# - una - Mejores prácticas para soluciones grandes en Visual Studio(2008)
que es una solucion en visual studio (12)
+1 para ahorrar el uso de carpetas de soluciones para ayudar a organizar cosas.
+1 para la construcción de proyectos en su propia carpeta. Inicialmente probamos una carpeta de salida común y esto puede llevar a sutiles y dolorosas a encontrar referencias desactualizadas.
FWIW, usamos referencias de proyectos para soluciones, y aunque nuget es probablemente una mejor opción en estos días, hemos encontrado que svn: external funciona bien para conjuntos propios de terceros y (tipo de marco) internos. Simplemente hágase el hábito de usar un número de revisión específico en lugar de HEAD cuando haga referencia a svn: externals (culpable como se le acusa :)
Tenemos una solución con más de 100 proyectos, la mayoría de C #. Naturalmente, lleva mucho tiempo abrir y construir, por lo que estoy buscando las mejores prácticas para tales bestias. A lo largo de las líneas de preguntas a las que espero obtener respuestas, están:
- cómo manejar las referencias entre proyectos
- ¿Debería estar "copiado localmente" encendido o apagado?
debería cada proyecto compilarse en su propia carpeta, o deberían compilar todos en la misma carpeta de salida (todos son parte de la misma aplicación)
¿Las carpetas de soluciones son una buena forma de organizar cosas?
Sé que dividir la solución en múltiples soluciones más pequeñas es una opción, pero eso viene con su propio conjunto de dolores de cabeza de refactorización y construcción, así que tal vez podamos guardar eso para un hilo separado :-)
Creo que con soluciones tan grandes, la mejor práctica debería ser romperlas. Puede pensar en la "solución" como un lugar para reunir los proyectos necesarios y tal vez otras piezas para trabajar en una solución a un problema. Al dividir los más de 100 proyectos en múltiples soluciones especializadas para desarrollar soluciones para solo una parte del problema general, puede tratar menos en un determinado momento acelerando sus interacciones con los proyectos requeridos y simplificando el dominio del problema.
Cada solución produciría la salida de la cual es responsable. Esta salida debe tener información de versión que se puede establecer en un proceso automatizado. Cuando el resultado es estable, puede actualizar las referencias en proyectos y soluciones dependientes con la distribución interna más reciente. Si aún desea ingresar al código y acceder a la fuente, puede hacerlo con el servidor de símbolos de Microsoft que Visual Studio puede usar para permitirle ingresar a los ensambles a los que hace referencia e incluso buscar el código fuente.
El desarrollo simultáneo se puede hacer especificando interfaces por adelantado y burlándose de los ensamblados en desarrollo mientras espera dependencias que no están completas pero que desea desarrollar en contra.
Encuentro que esta es una mejor práctica porque no hay límite para lo complejo que puede ser el esfuerzo general cuando lo desglosas físicamente de esta manera. Poner todos los proyectos en una sola solución eventualmente llegará a un límite superior.
Espero que esta información ayude.
Descargue los proyectos que no usa con frecuencia y compre un SSD. Un SSD no mejora el tiempo de compilación, pero Visual Studio se vuelve dos veces más rápido para abrir / cerrar / compilar.
En términos de aliviar el problema del edificio, puede usar la opción "Administrador de configuración ..." para compilaciones para habilitar o deshabilitar la construcción de proyectos específicos. Puede tener un "proyecto [n] compilación" que podría excluir ciertos proyectos y utilizarlo cuando esté orientando proyectos específicos.
En lo que respecta a los más de 100 proyectos, sé que no quiere que se le cuestione sobre los beneficios de reducir el tamaño de su solución, pero creo que no tiene otra opción cuando se trata de acelerar el tiempo de carga (y uso de memoria) devenv.
Establecer CopyLocal = false reducirá el tiempo de compilación, pero puede causar diferentes problemas durante el tiempo de implementación.
Hay muchos escenarios en los que debe tener Copy Local ''left to True, por ejemplo, proyectos de nivel superior, dependencias de segundo nivel, DLL llamados por reflexión.
Mi experiencia con la configuración de CopyLocal = false no fue exitosa. Ver el resumen de pro y contra en mi entrada de blog geekswithblogs.net/mnf/archive/2012/12/09/…
Lo que normalmente hago con esto depende un poco de cómo realmente ocurre el proceso de "depuración". Por lo general, aunque NO configuro la copia local para que sea verdadera. Configuré el directorio de compilación para cada proyecto para producir todo en el punto final deseado.
Por lo tanto, después de cada compilación tengo una carpeta poblada con todos los dll y cualquier aplicación de Windows / web y todos los elementos están en la ubicación correcta. No se necesitó copiar local ya que el dll termina en el lugar correcto al final.
Nota
Lo anterior funciona para mis soluciones, que generalmente son aplicaciones web y no he tenido problemas con las referencias, ¡pero podría ser posible!
Puede que le interesen estos dos artículos de MSBuild que he escrito.
MSBuild: mejores prácticas para crear construcciones confiables, parte 1
MSBuild: Mejores prácticas para crear construcciones confiables, Parte 2
Específicamente en la Parte 2 hay una sección Construyendo grandes fuentes de árboles que tal vez quiera echar un vistazo.
Para responder brevemente a sus preguntas aquí:
- CopyLocal? Por supuesto apagar esto
- ¿Construir en una o varias carpetas de salida? Crear en una carpeta de salida
- Carpetas de soluciones? Esta es una cuestión de gusto.
Sayed Ibrahim Hashimi
Mi libro: dentro del motor de compilación de Microsoft: usando MSBuild y Team Foundation Build
Tenemos más de 60 proyectos y no usamos archivos de soluciones. Tenemos una mezcla de proyectos C # y VB.Net. El rendimiento siempre fue un problema. No trabajamos en todos los proyectos al mismo tiempo. Cada desarrollador crea sus propios archivos de solución en función de los proyectos en los que están trabajando. Los archivos de la solución no se verifican en nuestro control de origen.
Todos los proyectos de la biblioteca Class se compilarán en una carpeta CommonBin en la raíz del directorio fuente. Proyectos ejecutables / Web construidos en su carpeta individual.
No usamos referencias de proyectos, en cambio, referencia basada en archivos de la carpeta CommonBin. Escribí una tarea personalizada de MSBuild que inspeccionaría los proyectos y determinaría el orden de compilación.
Hemos estado usando esto por algunos años y no tenemos quejas.
Tenemos un problema similar ya que tenemos 109 proyectos separados para tratar. Para responder las preguntas originales basadas en nuestras experiencias:
1. ¿Cómo manejas las referencias entre proyectos?
Usamos la opción del menú contextual ''agregar referencia''. Si se selecciona ''proyecto'', entonces la dependencia se agrega a nuestro único archivo de solución global de manera predeterminada.
2. ¿Se debe activar o desactivar "copiar local"?
Desactivado en nuestra experiencia. La copia adicional solo aumenta los tiempos de compilación.
3. ¿Debería cada proyecto crear su propia carpeta, o deberían compilar todos en la misma carpeta de salida (todos son parte de la misma aplicación)?
Toda nuestra salida se coloca en una sola carpeta llamada ''bin''. La idea es que esta carpeta sea la misma que cuando se implementa el software. Esto ayuda a prevenir problemas que ocurren cuando la configuración del desarrollador es diferente de la configuración de implementación.
4. ¿Las carpetas de soluciones son una buena forma de organizar cosas?
No en nuestra experiencia La estructura de carpetas de una persona es la pesadilla de otra persona. Las carpetas profundamente anidadas solo aumentan el tiempo que lleva encontrar algo. Tenemos una estructura completamente plana, pero el nombre de nuestros archivos de proyectos, ensambles y espacios de nombres es el mismo.
Nuestra forma de estructurar proyectos se basa en un único archivo de solución. Construir esto lleva mucho tiempo, incluso si los proyectos en sí mismos no han cambiado. Para ayudar con esto, normalmente creamos otro archivo de solución de "conjunto de trabajo actual". Cualquier proyecto en el que estamos trabajando se agrega a esto. Los tiempos de compilación han mejorado mucho, aunque un problema que hemos visto es que Intellisense falla para tipos definidos en proyectos que no están en el conjunto actual.
Un ejemplo parcial de nuestro diseño de solución:
/bin
OurStuff.SLN
OurStuff.App.Administrator
OurStuff.App.Common
OurStuff.App.Installer.Database
OurStuff.App.MediaPlayer
OurStuff.App.Operator
OurStuff.App.Service.Gateway
OurStuff.App.Service.CollectionStation
OurStuff.App.ServiceLocalLauncher
OurStuff.App.StackTester
OurStuff.Auditing
OurStuff.Data
OurStuff.Database
OurStuff.Database.Constants
OurStuff.Database.ObjectModel
OurStuff.Device
OurStuff.Device.Messaging
OurStuff.Diagnostics
...
[etc]
Tenemos un problema similar. Lo resolvemos usando soluciones más pequeñas. Tenemos una solución maestra que abre todo. Pero perf. en eso es malo. Por lo tanto, segmentamos soluciones más pequeñas por tipo de desarrollador. Por lo tanto, los desarrolladores de DB tienen la misma solución que los proyectos que les importan, los desarrolladores de servicios y los desarrolladores de UI. Es raro cuando alguien tiene que abrir toda la solución para obtener lo que necesitan hacer día a día. No es una panacea, tiene sus ventajas y desventajas. Consulte "modelo de soluciones múltiples" en este artículo (ignore la parte sobre el uso de VSS :)
Todo tiene que ver con su definición y visión de lo que son una solución y un proyecto. En mi opinión, una solución es solo eso, una agrupación lógica de proyectos que resuelve un requisito muy específico. Desarrollamos una gran aplicación de Intranet. Cada aplicación dentro de esa Intranet tiene su propia solución, que también puede contener proyectos para servicios antiguos o de Windows. Y luego tenemos un marco centralizado con cosas como clases base y ayudantes y httphandlers / httpmodules. El marco base es bastante grande y lo utilizan todas las aplicaciones. Al dividir las muchas soluciones de esta forma, se reduce la cantidad de proyectos requeridos por una solución, ya que la mayoría de ellos no tienen nada que ver entre sí.
Tener tantos proyectos en una solución es solo un mal diseño. No debería haber ninguna razón para tener tantos proyectos bajo una solución. El otro problema que veo es con referencias de proyectos, que realmente pueden arruinarlo eventualmente, especialmente si alguna vez quiere dividir su solución en otras más pequeñas.
Mi consejo es hacer esto y desarrollar un marco centralizado (su propia implementación de Enterprise Library si lo desea). Puede GAC compartirlo o puede hacer referencia directamente a la ubicación del archivo para que tenga una tienda central. También podría usar la misma táctica para objetos comerciales centralizados.
Si desea hacer referencia directamente a la DLL, querrá hacer referencia a ella en su proyecto con copy local false (en algún lugar como c: / mycompany / bin / mycompany.dll). En tiempo de ejecución, deberá agregar algunas configuraciones a su app.config o web.config para que haga referencia a un archivo que no está en el GAC o en el contenedor de tiempo de ejecución. En realidad, no importa si se trata de una copia local o no, o si el dll termina en el contenedor o incluso en el GAC, porque la configuración anulará ambas. Creo que es una mala práctica copiar local y tener un sistema desordenado. Lo más probable es que tenga que copiar local temporalmente si necesita depurar en uno de esos ensamblajes.
Puede leer mi artículo sobre cómo usar una DLL globalmente sin el GAC. Realmente no me gusta el GAC porque evita la implementación de xcopy y no activa un autortart en las aplicaciones.
Trabajamos en un gran proyecto similar aquí. Las carpetas de soluciones han demostrado ser una buena forma de organizar las cosas, y tendemos a simplemente dejar que el conjunto local de copias sea verdadero. Cada proyecto se construye en su propia carpeta, y luego sabemos que para cada proyecto desplegable allí tenemos el subconjunto correcto de los binarios en su lugar.
En cuanto a la apertura del tiempo y la creación de tiempo, va a ser difícil solucionarlo sin romper en soluciones más pequeñas. Podría investigar la paralelización de la compilación (google "Parallel MS Build" para una forma de hacerlo e integrarla en la interfaz de usuario) para mejorar la velocidad aquí. Además, fíjese en el diseño y vea si la refacturación de algunos de sus proyectos para reducir el total podría ayudar.