Tiempos de compilación muy lentos en Visual Studio 2005

https://stackoverflow.com/questions/55517

09-06-2019
|

Pregunta

Estamos obteniendo tiempos de compilación muy lentos, que pueden tardar más de 20 minutos en máquinas de doble núcleo de 2 GHz y 2G de RAM.

Mucho de esto se debe al tamaño de nuestra solución, que ha crecido a más de 70 proyectos, así como a VSS, que es un cuello de botella en sí mismo cuando tienes muchos archivos.(Desafortunadamente, cambiar VSS no es una opción, por lo que no quiero que esto se convierta en una fiesta de VSS)

Estamos pensando en fusionar proyectos.También buscamos tener múltiples soluciones para lograr una mayor separación de preocupaciones y tiempos de compilación más rápidos para cada elemento de la aplicación.Puedo ver que esto se convertirá en un infierno de DLL a medida que intentemos mantener las cosas sincronizadas.

Me interesa saber cómo otros equipos han abordado este problema de escala, qué haces cuando tu base de código alcanza una masa crítica que desperdicias la mitad del día viendo cómo la barra de estado entrega mensajes de compilación.

ACTUALIZAROlvidé mencionar que esta es una solución de C#.Gracias por todas las sugerencias de C++, pero han pasado algunos años desde que tuve que preocuparme por los encabezados.

EDITAR:

Buenas sugerencias que han ayudado hasta ahora (no digo que no haya otras buenas sugerencias a continuación, solo las que han ayudado)

Nueva computadora portátil de 3 GHz: el poder de la utilización perdida hace maravillas cuando se queja ante la gerencia
Deshabilitar antivirus durante la compilación
'Desconectarse' de VSS (en realidad, la red) durante la compilación. Es posible que eliminemos la integración VS-VSS por completo y sigamos usando la interfaz de usuario de VSS.

Todavía no estoy analizando una compilación, pero todo ayuda.

Orion mencionó en un comentario que los genéricos también pueden tener importancia.Según mis pruebas, parece haber un impacto mínimo en el rendimiento, pero no lo suficientemente alto como para estar seguro: los tiempos de compilación pueden ser inconsistentes debido a la actividad del disco.Debido a limitaciones de tiempo, mis pruebas no incluyeron tantos genéricos ni tanto código como aparecería en el sistema en vivo, por lo que es posible que se acumulen.No evitaría el uso de genéricos donde se supone que deben usarse, solo para el rendimiento en tiempo de compilación.

SOLUCIÓN ALTERNA

Estamos probando la práctica de crear nuevas áreas de la aplicación en nuevas soluciones, importando los archivos DLL más recientes según sea necesario e integrándolos en la solución más grande cuando estemos satisfechos con ellos.

También podemos hacer lo mismo con el código existente creando soluciones temporales que simplemente encapsule las áreas en las que necesitamos trabajar y desechándolas después de reintegrar el código.Necesitamos sopesar el tiempo que llevará reintegrar este código con el tiempo que ganamos al no tener experiencias similares a las de Rip Van Winkle con una recompilación rápida durante el desarrollo.

Solución

El equipo de Chromium.org enumeró varias opciones para acelerando la construcción (en este punto, aproximadamente a la mitad de la página):

En orden decreciente de aceleración:

Instalar revisión de Microsoft 935225.

Instalar revisión de Microsoft 947315.

Utilice un verdadero procesador multinúcleo (es decir,un Intel Core Duo 2;no un Pentium 4 HT).

Utilice 3 compilaciones paralelas.En Visual Studio 2005, encontrará la opción en Herramientas > Opciones...> Proyectos y soluciones > Construir y ejecutar > Número máximo de compilaciones de proyectos paralelos.

Desactive su software antivirus para archivos .ilk, .pdb, .cc, .h y solo compruebe si hay virus en modificar.Deshabilite el escaneo del directorio donde residen sus fuentes.No hagas nada estúpido.

Almacene y cree el código Chromium en un segundo disco duro.Realmente no acelerará la compilación, pero al menos su computadora seguirá respondiendo cuando realice la sincronización con el cliente o una compilación.

Desfragmenta tu disco duro periódicamente.

Desactiva la memoria virtual.

Otros consejos

Tenemos casi 100 proyectos en una solución y un tiempo de desarrollo de solo segundos :)

Para compilaciones de desarrollo local, creamos un complemento de Visual Studio que cambia Project references a DLL references y descarga los proyectos no deseados (y una opción para volver a cambiarlos, por supuesto).

Construya nuestra solución completa una vez
Descargue los proyectos en los que no estamos trabajando actualmente y cambie todas las referencias de proyectos a referencias DLL.
Antes del check-in, cambie todas las referencias de DLL a referencias del proyecto.

Nuestras compilaciones ahora solo toman unos segundos cuando trabajamos en solo unos pocos proyectos a la vez.También podemos depurar los proyectos adicionales ya que se vinculan a las DLL de depuración.La herramienta suele tardar entre 10 y 30 segundos en realizar una gran cantidad de cambios, pero no es necesario hacerlo con tanta frecuencia.

Actualización mayo 2015

El trato que hice (en los comentarios a continuación) fue que lanzaría el complemento en código abierto. si obtiene suficiente interés.4 años después tiene sólo 44 votos (y Visual Studio ahora tiene dos versiones posteriores), por lo que actualmente es un proyecto de baja prioridad.

Tuve un problema similar en una solución con 21 proyectos y 1/2 millón de LOC.La mayor diferencia fue conseguir discos duros más rápidos.Desde el monitor de rendimiento, el 'Promedio.Disk Queue' saltaba significativamente en la computadora portátil, lo que indicaba que el disco duro era el cuello de botella.

Aquí hay algunos datos sobre los tiempos totales de reconstrucción...

1) Computadora portátil, Core 2 Duo 2GHz, unidad de 5400 RPM (no estoy seguro del caché.Era Dell Inspiron estándar).

Tiempo de reconstrucción = 112 segundos.

2) Escritorio (edición estándar), Core 2 Duo 2,3 Ghz, unidad única de 7200 RPM y caché de 8 MB.

Tiempo de reconstrucción = 72 segundos.

3) Desktop Core 2 Duo 3Ghz, WD Raptor único de 10000 RPM

Tiempo de reconstrucción = 39 segundos.

La unidad de 10.000 RPM no puede subestimarse.Las compilaciones fueron significativamente más rápidas y todo lo demás, como mostrar documentación, usar el explorador de archivos fue notablemente más rápido.Fue un gran aumento de la productividad al acelerar el ciclo de creación y ejecución del código.

Dado lo que las empresas gastan en salarios de desarrolladores, es loco cuánto pueden desperdiciar comprándolos con las mismas PC que usa la recepcionista.

Para compilaciones de C# .NET, puede usar Demonio .NET.Es un producto que se hace cargo del proceso de compilación de Visual Studio para hacerlo más rápido.

Para ello, analiza los cambios que realizó y crea solo el proyecto que realmente cambió, así como otros proyectos que realmente se basaron en los cambios que realizó.Eso significa que si solo cambia el código interno, solo es necesario construir un proyecto.

Apague su antivirus.Agrega edades al tiempo de compilación.

Utilice compilación distribuida.xoreax IncrediBuild puede reducir el tiempo de compilación a unos pocos minutos.

Lo he usado en una enorme solución C\C++ que normalmente tarda entre 5 y 6 horas en compilarse.IncrediBuild ayudó a reducir este tiempo a 15 minutos.

Instrucciones para reducir el tiempo de compilación de Visual Studio a unos pocos segundos

Lamentablemente, Visual Studio no es lo suficientemente inteligente como para distinguir los cambios en la interfaz de un ensamblado de los cambios intrascendentes en el cuerpo del código.Este hecho, cuando se combina con grandes soluciones entrelazadas, a veces puede crear una tormenta perfecta de "compilaciones completas" no deseadas casi cada vez que se cambia una sola línea de código.

Una estrategia para superar esto es desactivar las compilaciones automáticas del árbol de referencia.Para hacer esto, use el 'Administrador de configuración' (Administrador de configuración/compilación... luego, en el menú desplegable Configuración de solución activa, elija 'Nuevo') para crear una nueva configuración de compilación llamada 'Compilación manual' que copia de la configuración de depuración, pero no No marque la casilla de verificación 'Crear nuevas configuraciones de proyecto'.En esta nueva configuración de compilación, desmarque todos los proyectos para que ninguno de ellos se genere automáticamente.Guarde esta configuración presionando 'Cerrar'.Esta nueva configuración de compilación se agrega a su archivo de solución.

Puede cambiar de una configuración de compilación a otra a través del menú desplegable de configuración de compilación en la parte superior de la pantalla de su IDE (el que generalmente muestra "Depurar" o "Liberar").Efectivamente, esta nueva configuración de compilación de ManualCompile inutilizará las opciones del menú de compilación para:'Crear solución' o 'Reconstruir solución'.Por lo tanto, cuando está en el modo de compilación manual, debe compilar manualmente cada proyecto que esté modificando, lo que se puede hacer haciendo clic derecho en cada proyecto afectado en el Explorador de soluciones y luego seleccionando 'Construir' o 'Reconstruir'.Deberías ver que tus tiempos generales de compilación ahora serán de solo unos segundos.

Para que esta estrategia funcione, es necesario que el número de versión que se encuentra en los archivos AssemblyInfo y GlobalAssemblyInfo permanezca estático en la máquina del desarrollador (no durante las versiones de lanzamiento, por supuesto) y que no firme sus archivos DLL.

Un riesgo potencial de utilizar esta estrategia ManualCompile es que el desarrollador podría olvidarse de compilar los proyectos necesarios y, cuando inicia el depurador, obtiene resultados inesperados (no se puede adjuntar el depurador, archivos no encontrados, etc.).Para evitar esto, probablemente sea mejor usar la configuración de compilación 'Depurar' para compilar un esfuerzo de codificación mayor y solo usar la configuración de compilación ManualCompile durante las pruebas unitarias o para realizar cambios rápidos que sean de alcance limitado.

Si se trata de C o C++ y no está utilizando encabezados precompilados, debería hacerlo.

Teníamos más de 80 proyectos en nuestra solución principal, cuya construcción tomó entre 4 y 6 minutos, dependiendo del tipo de máquina en la que estuviera trabajando el desarrollador.Consideramos que era demasiado largo:para cada prueba, realmente devora tus FTE.

Entonces, ¿cómo conseguir tiempos de construcción más rápidos?Como parece que ya sabes, es la cantidad de proyectos lo que realmente perjudica el tiempo de construcción.Por supuesto, no queríamos deshacernos de todos nuestros proyectos y simplemente juntar todos los archivos fuente en uno.Pero teníamos algunos proyectos que aún podíamos combinar:Como cada "proyecto de repositorio" en la solución tenía su propio proyecto de prueba unitaria, simplemente combinamos todos los proyectos de prueba unitaria en un proyecto de prueba unitaria global.Eso redujo la cantidad de proyectos con aproximadamente 12 proyectos y de alguna manera ahorró el 40% del tiempo para construir la solución completa.

Aunque estamos pensando en otra solución.

¿También ha intentado configurar una nueva (segunda) solución con un nuevo proyecto?Esta segunda solución debería simplemente incorporar todos los archivos que utilizan las carpetas de soluciones.Porque es posible que se sorprenda al ver el tiempo de construcción de esa nueva solución con un solo proyecto.

Sin embargo, trabajar con dos soluciones diferentes requerirá una cuidadosa consideración.Los desarrolladores podrían inclinarse a trabajar realmente en la segunda solución y descuidar por completo la primera.Como la primera solución con más de 70 proyectos será la solución que se ocupa de su jerarquía de objetos, esta debería ser la solución donde su servidor de compilación debería ejecutar todas sus pruebas unitarias.Entonces el servidor para la Integración Continua debe ser el primer proyecto/solución.Tienes que mantener tu jerarquía de objetos, ¿verdad?

La segunda solución con un solo proyecto (que se construirá mucho más rápido) será el proyecto en el que todos los desarrolladores realizarán las pruebas y la depuración.¡Sin embargo, debes cuidarlos mirando el servidor de compilación!Si algo se rompe, DEBE arreglarse.

Asegúrese de que sus referencias sean referencias del Proyecto y no directamente a las DLL en los directorios de salida de la biblioteca.

Además, configúrelos para que no se copien localmente, excepto cuando sea absolutamente necesario (el proyecto EXE maestro).

Publiqué esta respuesta originalmente aquí:https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473Puede encontrar muchos otros consejos útiles en esa página.

Si está utilizando Visual Studio 2008, puede compilar usando el indicador /MP para crear un único proyecto en paralelo.He leído que esta también es una característica no documentada en Visual Studio 2005, pero nunca lo he probado yo mismo.

Puede crear varios proyectos en paralelo utilizando el indicador /M, pero generalmente ya está configurado en la cantidad de núcleos disponibles en la máquina, aunque creo que esto solo se aplica a VC++.

Noto que esta pregunta tiene mucho tiempo, pero el tema sigue siendo de interés hoy en día.El mismo problema me afectó últimamente, y las dos cosas que mejoraron más el rendimiento de la compilación fueron (1) usar un disco dedicado (y rápido) para compilar y (2) usar la misma carpeta de salida para todos los proyectos y configurar CopyLocal en False en el proyecto. referencias.

Algunos recursos adicionales:

Algunas herramientas de análisis:

Herramientas-> Opciones-> VC ++ Configuración del proyecto-> Timing de compilación = Sí le dirá tiempo de construcción para cada VCProj.

Agregar /Bt cambie a la línea de comando del compilador para ver cuánto tomó cada archivo CPP

Usar /showIncludes para capturar inclusiones anidadas (archivos de encabezado que incluyen otros archivos de encabezado) y ver qué archivos podrían ahorrar una gran cantidad de IO mediante el uso de declaraciones directas.

Esto le ayudará a optimizar el rendimiento del compilador eliminando dependencias y acaparadores de rendimiento.

Antes de gastar dinero en discos duros más rápidos, intente construir su proyecto completamente en un disco RAM (suponiendo que tenga RAM de sobra).Puede encontrar varios controladores de disco RAM gratuitos en la red.No encontrará ninguna unidad física, incluidas las SSD, que sea más rápida que un disco RAM.

En mi caso, un proyecto que tardó 5 minutos en construirse en un i7 de 6 núcleos en una unidad SATA de 7200 RPM con Incredibuild se redujo en sólo unos 15 segundos usando un disco RAM.Teniendo en cuenta la necesidad de volver a copiar al almacenamiento permanente y la posibilidad de perder trabajo, 15 segundos no es un incentivo suficiente para usar un disco RAM y probablemente no sea un gran incentivo para gastar varios cientos de dólares en una unidad SSD o de altas RPM.

La pequeña ganancia puede indicar que la compilación estaba vinculada a la CPU o que el almacenamiento en caché de archivos de Windows fue bastante efectivo, pero como ambas pruebas se realizaron desde un estado en el que los archivos no estaban almacenados en caché, me inclino mucho hacia las compilaciones vinculadas a la CPU.

Dependiendo del código real que esté compilando, su kilometraje puede variar, así que no dude en realizar la prueba.

¿Qué tamaño tiene su directorio de compilación después de realizar una compilación completa?Si sigue con la configuración predeterminada, cada ensamblado que construya copiará todas las DLL de sus dependencias y las dependencias de sus dependencias, etc.a su directorio bin.En mi trabajo anterior, cuando trabajaba con una solución de ~40 proyectos, mis colegas descubrieron que, con diferencia, la parte más costosa del proceso de compilación era copiar estos ensamblados una y otra vez, y que una compilación podía generar gigabytes de copias de las mismas DLL una y otra vez. otra vez.

Aquí hay algunos consejos útiles de Patrick Smacchia, autor de NDepend, sobre lo que él cree que deberían y no deberían ser asambleas separadas:

http://codebetter.com/patricksmacchia/2008/12/08/advices-on-partitioning-code-through-net-assemblies/

Básicamente, hay dos formas de solucionar este problema y ambas tienen desventajas.Una es reducir el número de asambleas, lo que obviamente supone mucho trabajo.Otra es reestructurar sus directorios de compilación para que todas sus carpetas bin estén consolidadas y los proyectos no copien las DLL de sus dependencias; no es necesario porque ya están todas en el mismo directorio.Esto reduce drásticamente la cantidad de archivos creados y copiados durante una compilación, pero puede ser difícil de configurar y puede dejarle con cierta dificultad para extraer solo las DLL requeridas por un ejecutable específico para empaquetar.

Quizás tome algunas funciones comunes y cree algunas bibliotecas, de esa manera las mismas fuentes no se compilarán una y otra vez para múltiples proyectos.

Si le preocupa que se mezclen diferentes versiones de archivos DLL, utilice bibliotecas estáticas.

Desactive la integración VSS.Es posible que no tenga opción a usarlo, pero las DLL cambian de nombre "accidentalmente" todo el tiempo...

Y definitivamente verifique la configuración del encabezado precompilado.La guía de Bruce Dawson es un poco antigua, pero aún así muy bueno, compruébalo: http://www.cygnus-software.com/papers/precompiledheaders.html

Tengo un proyecto que tiene 120 o más archivos ejecutables, bibliotecas y archivos DLL y lleva un tiempo considerable construirlo.Utilizo un árbol de archivos por lotes que llaman a crear archivos desde un archivo maestro por lotes.He tenido problemas con cosas raras de encabezados incrementales (o fueron temperamentales) en el pasado, así que ahora los evito.No hago una construcción completa con frecuencia y normalmente la dejo para el final del día mientras salgo a caminar durante una hora (por lo que sólo puedo suponer que me llevará aproximadamente media hora).Entonces entiendo por qué eso es inviable para trabajar y probar.

Para trabajar y probar, tengo otro conjunto de archivos por lotes para cada aplicación (o módulo o biblioteca) que también tienen todas las configuraciones de depuración implementadas, pero aún llaman a los mismos archivos de creación.Puedo activar o desactivar DEBUG de vez en cuando y también decidir sobre compilaciones o marcas o si también quiero compilar bibliotecas de las que el módulo pueda depender, etc.

El archivo por lotes también copia el resultado completo en las (o varias) carpetas de prueba.Dependiendo de la configuración, esto se completa en varios segundos a un minuto (en lugar de media hora).

Utilicé un IDE diferente (Zeus) porque me gusta tener control sobre cosas como archivos .rc y, de hecho, prefiero compilar desde la línea de comandos, aunque estoy usando compiladores de MS.

Feliz de publicar un ejemplo de este archivo por lotes si alguien está interesado.

Deshabilite la indexación del sistema de archivos en sus directorios de origen (específicamente los directorios obj si desea que se pueda buscar su fuente)

Si se trata de una aplicación web, configurar la compilación por lotes en verdadero puede ayudar según el escenario.

<compilation defaultLanguage="c#" debug="true" batch="true" >

Puede encontrar una descripción general aquí: http://weblogs.asp.net/bradleib/archive/2005/12/06/432441.aspx

También es posible que desees comprobar si hay referencias de proyectos circulares.Una vez fue un problema para mí.

Eso es:

El proyecto A hace referencia al proyecto B

El proyecto B hace referencia al proyecto C

El proyecto C hace referencia al proyecto A.

Una alternativa más económica a Xoreax IB es el uso de lo que yo llamo compilaciones de súper archivos.Es básicamente un archivo .cpp que tiene

#include "file1.cpp"
#include "file2.cpp"
....
#include "fileN.cpp"

Luego compilas las unidades súper en lugar de los módulos individuales.Hemos visto tiempos de compilación desde 10 a 15 minutos hasta 1 a 2 minutos.Es posible que tengas que experimentar cuántos #includes por archivo uber tienen sentido.Depende de los proyectos.etc.Quizás incluyas 10 archivos, quizás 20.

Pagas un costo así que ten cuidado:

No puede hacer clic derecho en un archivo y decir "compilar..." ya que debe excluir los archivos cpp individuales de la compilación e incluir solo los archivos uber cpp.
Hay que tener cuidado con los conflictos de variables globales estáticas.
Cuando agregas nuevos módulos, debes mantener los archivos de Uber actualizados.

Es un poco molesto, pero para un proyecto que es en gran medida estático en términos de nuevos módulos, el dolor inicial podría valer la pena.He visto que este método venció a IB en algunos casos.

Si es un proyecto de C++, entonces deberías usar encabezados precompilados.Esto marca una gran diferencia en los tiempos de compilación.No estoy seguro de qué está haciendo realmente cl.exe (sin usar encabezados precompilados), parece estar buscando lotes de encabezados STL en todos los lugares equivocados antes de finalmente ir a la ubicación correcta.Esto agrega segundos enteros a cada archivo .cpp que se compila.No estoy seguro si se trata de un error de cl.exe o algún tipo de problema STL en VS2008.

Si observa la máquina en la que está construyendo, ¿está configurada de manera óptima?

Acabamos de reducir el tiempo de construcción de nuestro mayor producto C++ a escala empresarial desde 19 horas a 16 minutos asegurándose de que se haya instalado el controlador de filtro SATA correcto.

Sutil.

Hay un modificador /MP no documentado en Visual Studio 2005, consulte http://lahsiv.net/blog/?p=40, lo que permitiría la compilación paralela en base a archivos en lugar de proyectos.Esto puede acelerar la compilación del último proyecto o, si compila un proyecto.

Al elegir una CPU:El tamaño de la caché L1 parece tener un gran impacto en el tiempo de compilación.Además, suele ser mejor tener 2 núcleos rápidos que 4 lentos.Visual Studio no utiliza los núcleos adicionales de manera muy efectiva.(Me baso en mi experiencia con el compilador de C++, pero probablemente también sea cierto para el de C#).

Ahora también estoy convencido de que hay un problema con VS2008.Lo estoy ejecutando en una computadora portátil Intel de doble núcleo con 3G Ram, con el antivirus desactivado.Compilar la solución suele ser bastante sencillo, pero si he estado depurando, una recompilación posterior a menudo se ralentizará.De la luz continua del disco principal se desprende claramente que hay un cuello de botella de E/S del disco (también puedes oírlo).Si cancelo la compilación y apago VS, la actividad del disco se detiene.Reinicie VS, vuelva a cargar la solución y luego reconstruya, y es mucho más rápido.Hasta la próxima vez

Mi opinión es que se trata de un problema de paginación de memoria: VS simplemente se queda sin memoria y el sistema operativo comienza a intercambiar páginas para intentar hacer espacio, pero VS exige más de lo que el intercambio de páginas puede ofrecer, por lo que se ralentiza.No se me ocurre ninguna otra explicación.

VS definitivamente no es una herramienta RAD, ¿verdad?

¿Por casualidad su empresa utiliza Entrust para su solución PKI/cifrado?Resulta que teníamos un rendimiento de compilación abismal para un sitio web bastante grande creado en C#, lo que nos llevó más de 7 minutos en Rebuild-All.

Mi máquina es una i7-3770 con 16 GB de RAM y 512 GB de SSD, por lo que el rendimiento no debería haber sido tan malo.Noté que mis tiempos de compilación eran increíblemente más rápidos en una máquina secundaria más antigua que creaba la misma base de código.Entonces encendí ProcMon en ambas máquinas, perfilé las compilaciones y comparé los resultados.

He aquí que la máquina de rendimiento lento tenía una diferencia: una referencia a Entrust.dll en el seguimiento de pila.Usando esta información recién adquirida, continué buscando en StackOverflow y encontré esto: MSBUILD (VS2010) muy lento en algunas máquinas.Según la respuesta aceptada, el problema radica en el hecho de que el controlador Entrust estaba procesando las comprobaciones de certificados .NET en lugar del controlador nativo de Microsoft.También se sugiere que Entrust v10 resuelva este problema que prevalece en Entrust 9.

Actualmente lo tengo desinstalado y mis tiempos de compilación se desplomaron a 24 segundos.YYMV con la cantidad de proyectos que está construyendo actualmente y es posible que no aborde directamente el problema de escala sobre el que estaba preguntando.Publicaré una edición de esta respuesta si puedo proporcionar una solución. sin recurriendo a una desinstalación del software.

Es seguro que hay un problema con VS2008.Porque lo único que hice fue instalar VS2008 para actualizar mi proyecto que fue creado con VS2005.Solo tengo 2 proyectos en mi solución.No es grande.Compilación con VS2005:30 Secondes Compilación con VS2008:5 minutos

Buenas sugerencias que han ayudado hasta ahora (sin decir que no haya otras buenas sugerencias a continuación, si tiene problemas, le recomiendo leer, solo lo que nos ha ayudado)

Nueva computadora portátil de 3 GHz: el poder de la utilización perdida hace maravillas cuando se queja ante la gerencia
Deshabilitar antivirus durante la compilación
'Desconectarse' de VSS (en realidad, la red) durante la compilación. Es posible que eliminemos la integración VS-VSS por completo y sigamos usando la interfaz de usuario de VSS.

Todavía no estoy analizando una compilación, pero todo ayuda.

También estamos probando la práctica de crear nuevas áreas de la aplicación en nuevas soluciones, importando los archivos DLL más recientes según sea necesario e integrándolos en la solución más grande cuando estemos satisfechos con ellos.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow