2009-04-21 14 views
8

Actualmente estoy involucrado en un proyecto ASP.NET con aproximadamente 40 proyectos en la solución. Estamos haciendo todo nuestro desarrollo en entornos clonados de PC virtual para que todos los desarrolladores tengan configuraciones idénticas. Eso está bien, administrar dependencias es fácil, sin embargo, construir la solución es terriblemente lento. Virtual PC solo puede utilizar una CPU, así que solo estoy usando la mitad de los recursos de mi computadora.Acelerando los tiempos de compilación en ASP.NET

Tarda unos 3 minutos completos desde la compilación hasta una carga de página completa ... y cada día va empeorando a medida que crecen los proyectos. Reparar cosas simples está comenzando a tomar mucho tiempo y, personalmente, me siento frustrado esperando todo el tiempo porque realmente no puedo trabajar mientras la computadora está compilando.

¿Hay alguna forma de distribuir mi compilación en varias computadoras para acelerar el proceso de compilación?

¿Mejoraría notablemente un SSD mis tiempos de construcción?

¿Hay alguna otra forma de acelerar la construcción?

Nota: He tratado precompilar dependencias estáticas con NGEN pero después de leer que ASP.NET no admite NGEN. Uso Visual Studio 2008 y no hay software antivirus presente en el entorno virtual.

+1

¿El tiempo de compilación es lento o ASP.NET tarda mucho tiempo en iniciar la primera página? – edosoft

+0

Ambos, son aproximadamente 2/3 compilación y 1/3 ASP.NET – zidar

Respuesta

3

Necesita reconstruir los 40 proyectos cada vez.

Puede configurar lo que se genera en la configuración de Configuración de la solución.

I.e. Si sus cambios solo están en su Proyecto WebUI, y los otros 39 proyectos no han cambiado, puede crear una configuración de compilación donde solo se reconstruya su aplicación web.

  • Mira la configuración desplegable
  • Haga clic en "Administrador de configuración"
  • En la "Configuración de soluciones activas" desplegable, haga clic en "Nuevo"
  • Crear una nueva configuración copiada de la configuración de depuración
  • En su nueva configuración, desmarque todas las compilaciones de proyectos excepto las que haya realizado cambios en
+1

Sin embargo, si no hay ningún cambio en los proyectos más bajos, msbuild es lo suficientemente inteligente como para darse cuenta de que nada ha cambiado y no los reconstruye. Cuando realiza un cambio en un archivo para volver a compilar, se recompilará a sí mismo y todas sus dependencias. –

+0

Pero entonces, ¿cómo sé que no rompo la construcción en esos proyectos que no construyo? – zidar

+0

Solo crea proyectos "Arriba" del proyecto al que hizo cambios en su cadena de dependencia ... Si tiene 39 proyectos DLL, a los que se hace referencia en su aplicación web, y solo cambia su aplicación web, entonces los cambios ganaron no rompa nada hacia abajo –

1

No mencionó su Visual St versión de audio, pero si se trata de 2005 es posible que desee considerar una actualización a 2008. En mi caso, esto disminuyó el tiempo de construcción en una solución grande (más de 30 proyectos).

Otra opción es crear previamente una serie de bibliotecas que ya no cambian y hacer referencia a las dll compiladas en lugar de a los proyectos.

+0

Uso VS 2008. La preconstrucción en realidad no ayuda mucho ya que los únicos proyectos que ya no cambiamos son pequeños y probablemente se desarrollen bastante rápido de todos modos. – zidar

1

Tenemos una situación similar, y descubrí que nuestras máquinas virtuales estaban siendo muy aceleradas, por lo que aunque cada una de ellas se ejecutaba en una sola CPU, no podían utilizarla por completo. Me las arreglé para obtener 3 virtuales que se ejecutan en un examen físico para que todos sean 100% más rápidos.


También me gustaría tratar de reducir el número de proyectos. Nuestras soluciones principales tienen 40 proyectos, y los he estado consolidando lentamente y asegurándome de que el nuevo desarrollo se ajuste a los proyectos existentes siempre que sea posible. Los principales culpables de esto fueron los servicios web, donde cada uno se había creado originalmente en un proyecto separado.Ahora estoy agregando todos los nuevos servicios web en un solo proyecto, y moviendo lentamente a los demás.

2

de Scott Gu tiene un puesto bastante útil acerca de esto:

Tip/Trick: Optimizing ASP.NET 2.0 Web Project Build Performance with VS 2005

Scott también tiene otro artículo sobre la velocidad de este disco duro, que también tiene un impacto en el rendimiento general de Visual Studio:

Tip/Trick: Hard Drive Speed and Visual Studio Performance

+2

Otro aspecto a tener en cuenta es la configuración del antivirus para escanear archivos en lectura/escritura. Me parece ventajoso excluir mi (s) carpeta (s) de trabajo de la exploración de acceso AV. –

+0

@thedorko - Estoy de acuerdo, y Scott Gu aborda esto (entre otras cosas) en el primer artículo al que me he vinculado. – CraigTP

+1

Ah, es suficiente. ¡Es malo por no leer el artículo! –

0

¿Has probado tuning up virtual PC?

http://www.windowsnetworking.com/articles_tutorials/Tuning-Virtual-PC-Performance.html

viejo artículo, pero la esencia sigue siendo correcta.

Encontré, en una situación similar, que tener un disco duro separado para las imágenes de disco de VPC acelera notablemente el rendimiento, especialmente al eliminar parte de la aceleración.

Quizás el problema no sea Visual Studio, es solo el hecho de que la compilación consume muchos recursos.

+0

La imagen se ejecuta desde una unidad desfragmentada por separado y tengo un sistema de doble núcleo. Al compilar, la CPU virtual única alcanza el 100% de uso prácticamente a través de todo el proceso de compilación ... no del disco duro. – zidar

+0

Cuando dice "CPU virtual única", ¿se refiere a la CPU dentro de la máquina virtual o al núcleo único en la máquina principal? – DavidWhitney

+0

Oh, lo siento, pobre redacción allí tal vez. Quise decir la CPU dentro de la máquina virtual. – zidar

1

También podría considerar cambiar a VMware Workstation, que utiliza múltiples procesadores. Actualmente estoy usando una configuración con dos máquinas virtuales de dos procesadores, y las cuatro sí se usan.

2

No ponga tantos proyectos en sus soluciones. Solo cree un nuevo proyecto cuando el código se ejecute en un proceso diferente o en una máquina diferente. De nada sirve crear tantos proyectos en la mayoría de los casos. La cantidad de proyectos es la desaceleración más significativa en msbuild.

+0

Es cierto, eso parece relevante. Podría tratar de reducir el número de proyectos si tengo el tiempo, sin embargo, dudo que a la gerencia le guste eso. Este es un sistema bastante grande con varios componentes diferentes y capas múltiples de abstracción ... no todos pueden estar en el mismo proyecto. – zidar

+0

¿Las capas se ejecutan en varios niveles físicos? – Paco

+0

Podría, sin embargo, consolidar grupos de proyectos en soluciones relevantes. Significa que necesita cambiar soluciones o usar varias instancias de VS de vez en cuando, pero es mucho más manejable. – DavidWhitney

1

Lo que hicimos en nuestra empresa es utilizar la referencia de archivos, por lo que solo los proyectos modificados deben construirse, y en un momento dado no hay más de 10 proyectos en mi solución, en su mayoría se construyen 2 ~ 3.

También construimos nuestro tronco para cada check-in, y tenemos un archivo por lotes para que los desarrolladores extraigan los dlls más recientes.

Por supuesto, esto no detiene el doloroso error de referencia de montaje, pero se convierten más en una molestia que un problema después de un tiempo.

6

Se puede reducir considerablemente el tiempo de espera para una construcción con ASP.NET de la siguiente manera:

  • Usar la nueva bandera "optimizeCompilations". Le dirá a .NET que no reconstruya todo el proyecto solo porque haya cambiado un proyecto/dll. Si tiene 40 proyectos y no los usa, cada vez que cambie un método simple en un proyecto, .NET intentará compilar todos los demás proyectos y dlls. Con la nueva bandera (más la instalación de una revisión) verá un gran aumento del rendimiento general durante el desarrollo. Échele un vistazo a esta publicación de blog con detalles sobre cómo acelerar la compilación con esta bandera de optimizeCompilations: http://www.wagnerdanda.me/2009/11/optimizing-asp-net-build-time-with-dynamic-compilation-and-optimizecompilations/

Espero que ayude!

Wagner da Silva Danda

+1

¿Por qué no está activado por defecto? Parece que está haciendo maravillas en algunos proyectos. – zidar

+1

A partir de Windows 7 no será necesario instalar la revisión para utilizar el indicador 'optimizeCompilations'. Lo mismo estará disponible con .NET Framework 4.0. Sin embargo, usar esta bandera es una opción agresiva que se debe considerar cuidadosamente. Es útil en la mayoría de los casos, pero tiene algunas desventajas. Consulte esta publicación http://msdn.microsoft.com/en-us/library/ms366723.aspx (sección "Desventajas de la compilación dinámica") para comprenderla. – wdanda

4

Y aquí es otra punta para acelerar los tiempos de construcción con ASP.NET:

espero que ayude!

Wagner Danda da Silva

Cuestiones relacionadas