Razones para reconstruir proyectos C# en Visual Studio

Question

Tengo una gran solución, de unos 320 proyectos, donde incluso pequeños cambios en un único formulario web dan como resultado largos tiempos de compilación para probar/depurar un pequeño cambio. Sospecho que las tareas de copia de archivo posteriores a la compilación para 'tocar' las fechas de los archivos y causar varias reconstrucciones.

¿Hay alguna otra razón para que VS 2010 ejecute una reconstrucción distinta de los archivos de origen que sean más nuevos que los archivos de salida binarios, a falta de fuertes influencias de nomenclatura y control de versiones?

ADDENDUM: No tengo influencia inmediata en el tamaño o la forma del árbol de fuentes. Es el tronco de un producto central estable y cualquier cambio "no comercial" a corto plazo se considera arriesgado o costoso. Subiré los puntos mencionados en las respuestas que recibo aquí como entrada para las direcciones futuras del proyecto.

Answer 1

C# se reconstruye porque se ha cambiado un archivo, o se ha cambiado una dependencia, pero también con frecuencia por "razones no obvias". A menudo puede compilar 2 o 3 veces seguidas sin hacer un solo cambio y C# arrancará y reconstruirá grandes cantidades del código.

Active Herramientas> Opciones> Proyectos y soluciones> Compilación y ejecución> Solo cree proyectos de inicio y dependencias en ejecución. Esto minimizará la compilación solo a las dependencias del proyecto que pretendes ejecutar, por lo tanto, a menos que todo sea un árbol de dependencias masivas, esto reducirá significativamente el número de proyectos considerados en la compilación.

La mejor solución, sin embargo, es evitar pedir que se compile en primer lugar.

• Cada proyecto agrega una sobrecarga adicional a la construcción. En mi PC esto es alrededor de 3 segundos. Al combinar el código de dos proyectos en un archivo .csproj, guardo 3 segundos de tiempo de compilación. Por lo tanto, para más de 300 proyectos, puede demorar 10 minutos en el tiempo de compilación solo fusionando proyectos; es decir, cuando sea posible, use muchos módulos/espacios de nombres en un ensamblaje en lugar de muchos ensamblajes. Descubrirá que el tiempo de inicio de la aplicación también ha mejorado.

• Muchos proyectos no necesitan construir todo el tiempo. Divulgarlos como proyectos de biblioteca y simplemente vincular a (referencia) los archivos binarios

• También deshabilitar "copiar local" y en su lugar señalar todos los OutputPaths a una carpeta compartida - esto reducirá significativamente los gastos generales evitando hacer 320 copias de 320 dlls en todo tu disco duro.

• Agrega nuevas configuraciones de compilación (por ejemplo, "Debug FastBuild") que solo construyen los ensamblajes en los que estás trabajando realmente.Con el administrador de configuración puede desmarcar proyectos que no desea compilar, y listo, el sistema de compilación los ignora. Después de obtener el código de control de código fuente, construir una "depuración" lleno construir para refrescar todo y, a continuación, volver a "FastBuild"

Answer 2

320 Proyectos es una gran cantidad de archivos en el árbol de dependencias: el motor de compilación debe verificar todos los cambios. El uso de algo como Process Monitor le permitirá ver qué operaciones de archivos están llevando a cabo para confirmar esto.

También 320 conjuntos (en la parte superior de los ensamblados de .NET framework) para cargar en tiempo de ejecución ralentizarán su aplicación, y realmente ralentizarán el depurador (se cargarán muchos símbolos). Mira la depuración | Windows | Módulos para ver los módulos cargados).

Además de reducir el número de proyectos en la solución (es bastante posible tener múltiples soluciones cada una con un subconjunto de los proyectos) ¿realmente necesita tantos proyectos por separado? Fuera del depurador, el cargador .NET solo carga y JIT el código de los ensamblajes según sea necesario, los ensamblajes más grandes no implican tiempos de carga más lentos y evitan los costos indirectos de ensamblaje del cargador de Windows.

Answer 3

Usted puede tratar de construir su solución utilizando msbuild y/v: d (por registro de diagnóstico).

Puede haber indicios en el registro de por qué un proyecto no está actualizado.

Answer 4

Primero, verifique que las referencias a otros proyectos sean referencias PROYECTO y no referencias de ensamblado.

En segundo lugar, verifique si hay referencias circulares.

En tercer lugar, establezca la verbosidad de registro en DIAGNOSTIC y observe la primera línea y vea por qué está reconstruyendo proyectos después de crear la solución por primera vez.

Hay mucho más que se puede comprobar, pero échale un vistazo a esas 3 cosas primero.

Answer 5

Creo que en 320 proyectos hace mucho tiempo que excediste el límite de lo que Visual Studio fue diseñado para hacer cómodamente.

Aquí hay muchos buenos consejos, pero si realmente debe mantener 320 proyectos, puede que desee deshacerse de Visual Studio para construir y diseñar su propio proceso de compilación.

Como dije en mi comentario, al menos en Windows, mi recomendación para una herramienta de compilación es psake que está construida en powershell (y por lo tanto incluida en todas las máquinas de Windows modernas), bastante potente y liviana para comprometer todo cosa a su control de fuente.