c# - valid - Visual Studio reconstruye proyectos no modificados

visual studio summary shortcut

Question

Entonces, como dice el título, tengo una solución VS2010 con ~ 50 proyectos en este momento. Si realizo un cambio en un proyecto de "nivel superior" al que nada hace referencia, VS aún reconstruye los 50 proyectos. Estoy ejecutando Visual Studio 2010 Ultimate sin complementos. Estoy usando ILMerge para consolidar todos los proyectos en un solo archivo.

Lo he verificado comprobando las marcas de tiempo de los dlls de nivel inferior y veo que, de hecho, se han reconstruido aunque no se haya tocado su código.

He leído todas las respuestas y comentarios para:

Visual Studio 2008 sigue reconstruyendo

Visual Studio sigue construyendo todo

Problema de compilación de VS2010 extraño en mi solución

Razones para reconstruir proyectos C # en Visual Studio

Pero la mayoría de ellos solo ofrece sugerencias sobre la descarga de proyectos para acelerar los tiempos de construcción, pero no hay nada concreto en cuanto a una solución. Intento descubrir por qué VS piensa que estos proyectos dependientes deben reconstruirse cuando no es así y solucionarlos.

He activado ''Herramientas> Opciones> Proyectos y soluciones> Crear y ejecutar> Solo crear proyectos de inicio y dependencias en ejecución'' pero sin efecto.

Además, si solo reconstruyo un proyecto de "nivel medio" que solo tiene 8 (en) dependencias directas, entonces sigue construyendo los 8 proyectos aunque ILMerge no se invoque y ninguno de los proyectos dependientes haya sido modificado.

Gracias a todos por cualquier idea que puedan proporcionar.

Adicional

Para probar algunas de las sugerencias, creé un nuevo proyecto de WinForms desde cero. Luego creé dos nuevos proyectos dentro de esa solución. Copié todo el código y los recursos (no el archivo del proyecto) de mis dos proyectos de ''nivel más bajo'' en los dos nuevos proyectos (lo hice soltando los archivos y carpetas de Explorer en el proyecto en Visual Studio).

El proyecto más bajo, llamémoslo B , no hizo referencia a ningún otro proyecto. El próximo proyecto, A , referenciado solo B. Entonces, una vez que agregué las referencias requeridas de .NET y del ensamble externo a los proyectos, entonces la solución se generaría.

Luego tuve mi nueva referencia de proyecto WinForm A e hice una compilación completa. Entonces, la cadena de ref es:

WinForm -> A -> B

Luego modifiqué WinForm solo e hice una compilación estándar (F6). Como antes, Visual Studio reconstruyó los tres proyectos.

Después de una selección elemental sistemática de los archivos fuente en el proyecto B , descubrí que si eliminé mis Resources.Designer.cs y Resources.resx (y comenté el código que hizo uso del objeto .Properties.Resources de esos recursos), entonces una modificación de WinForm ya no volvería a generar la solución completa y solo volvería a generar WinForm .

Agregar de nuevo Resources.resx y Resources.Designer.cs al proyecto B (pero dejando el código de referencia comentado de manera que nada hiciera uso de los recursos) volvería a introducir el comportamiento de compilación completo.

Para ver si mis archivos de recursos estaban dañados, los eliminé de nuevo y luego creé uno nuevo (a través de Propiedades del proyecto -> Recursos) y volví a agregar el mismo recurso que antes, que era un único archivo de Excel. Con esta configuración, la reconstrucción completa aún ocurrirá.

Luego eliminé el único recurso, pero dejé el archivo de recursos en el proyecto B. Incluso sin recursos agregados, pero el archivo de recursos todavía está en el proyecto, se produciría la reconstrucción completa (innecesaria).

Parece que el simple hecho de tener un archivo de recursos agregado a un proyecto (.NET 3.5) hará que Visual Studio 2010 siempre reconstruya ese proyecto. ¿Es esto un error o un comportamiento previsto / esperado?

Gracias a todos de nuevo!

Answer 1

Abrir Herramientas - Opciones, seleccionar Proyectos y Soluciones - Construir y Ejecutar en árbol, luego establecer "Verbosidad de salida de compilación del proyecto MSBuild" en Diagnóstico. Esto generará la razón para construir un proyecto, es decir,

El proyecto ''ReferencedProject'' no está actualizado. El elemento del proyecto ''c: / some.xml'' tiene el atributo ''Copiar en directorio de salida'' establecido en ''Copiar siempre''.

El proyecto ''MyProject'' no está actualizado. El archivo de entrada ''c: / ReferencedProject.dll'' se modifica después del archivo de salida ''c: / MyProject.pdb''.

En este caso, la solución es copiar algunos.xml solo si es más nuevo.

Los eventos de compilación previa y posterior también pueden generar compilación.

Answer 2

Aquí hay una respuesta de VS2010 siempre reconstruye la solución.

Este problema se soluciona cambiando los archivos del proyecto, la solución de limpieza, eliminando manualmente todas las carpetas de bin, reiniciando Visual Studio y reconstruyendo todo.

Answer 3

El equipo de MSBuild está reuniendo documentación sobre la investigación de problemas de incrementos de compilación aquí: https://github.com/Microsoft/MSBuild/wiki/Rebuilding%20when%20nothing%20changed

Answer 4

En mi caso, el culpable era la configuración "Copiar local" de un dll referenciado establecido en verdadero y "Copiar al directorio de salida" configurando un archivo configurado en Copiar siempre.

Answer 5

Esto sucede cuando un proyecto tiene un archivo que realmente no existe.
El proyecto no puede determinar si el archivo fue cambiado (porque no está allí) por lo que se reconstruye.

Simplemente mire todos los archivos del proyecto y busque uno que no tenga una flecha expansible cerca.

Answer 6

Finalmente encontré un culpable más que me costó encontrar al aumentar la verbosidad del registro de compilación.

En algunos casos, MSBuild busca vc120.pdb en la carpeta de salida, y si este archivo no existe, reconstruirá todo el proyecto. Esto ocurre incluso si ha desactivado la generación de símbolos de depuración .

La solución aquí es habilitar los símbolos de depuración y dejar que se genere este archivo, luego deshabilitar la configuración nuevamente sin eliminar el archivo PDB.

Answer 7

Otro problema que ocurre con frecuencia es cuando algún elemento en su solución tiene un sello modificado que está en el futuro. Esto puede suceder si adelanta el reloj y luego ajusta el reloj a la hora correcta. Esto sucedió durante la instalación de Linux.

En este caso, puede tocar recursivamente todos los archivos usando git bash (sí, en Windows):

find . -exec touch {} /;

Answer 8

Para esta categoría de problemas de compilación, establecer la verbosidad de salida de MSBuild en ''diagnóstico'' es de hecho un primer paso necesario. La mayoría de las veces, la razón declarada para las reconstrucciones sería suficiente para actuar, PERO ocasionalmente, MSBuild alegaría erróneamente que algunos archivos se han modificado y deben copiarse.

Si ese es el caso, necesitaría deshabilitar el túnel NTFS o duplicar su carpeta de salida a una nueva ubicación. this

Answer 9

Según sus observaciones, parece que tiene proyectos que expresan dependencias a otros proyectos de una manera que no es obvia. Es posible que las dependencias huérfanas permanezcan en los archivos del proyecto sin que aparezcan en la interfaz de usuario. ¿Has revisado un archivo de proyecto que funciona mal después de abrirlo en un editor de texto? ¿Revisó las dependencias de compilación de la solución?

Si no puede detectar nada, intente volver a crear uno de sus proyectos desde cero para ver si el nuevo proyecto presenta el mismo problema. Si el proyecto limpio se crea correctamente, sabrá que tiene dependencias no deseadas expresadas en alguna parte. Por lo que yo sé, estos deberían estar en los archivos del proyecto o en el archivo de la solución, a menos que tenga makefiles u otros pasos de compilación inusuales.

Answer 10

Si bien no creo que esto sea una solución, es una solución que ha funcionado para mi situación ...

Originalmente tenía aproximadamente 5 proyectos de los 50 que contenían una sección de Resources . Estos proyectos siempre serían reconstruidos y, por lo tanto, cualquier cosa de la que dependieran también sería reconstruida. Uno de esos 5 proyectos era una biblioteca de nivel "base" a la que se referían 48 de los otros proyectos, por lo tanto, el 96% de mi proyecto se reconstruiría cada vez, incluso si no lo necesitara.

Mi solución fue utilizar inyección de dependencias, interfaces y un proyecto dedicado de "Recursos". En lugar de hacer que esos 5 proyectos hicieran referencia a su propio objeto de Resources , creé una interfaz en cada proyecto que proporcionaría los recursos deseados. Entonces, las clases que necesitaban esos recursos requerirían que la interfaz se transfiriera durante su creación en el constructor (inyección de constructor).

Luego creé un proyecto de "Recursos" separado que tenía una sección de Recursos real como normal. Este proyecto solo contenía los recursos en sí, y una clase para cada interfaz que se necesitaba para proporcionar esos recursos a través de una interfaz. Este proyecto haría referencia a cualquier otro proyecto que tuviera una dependencia de recursos e implementaría la interfaz que necesitaba el proyecto.

Finalmente, en mi proyecto de "Nivel superior", al que no se hace referencia (y donde se construyó realmente el ejecutor y mi raíz de composición vive) mencioné el proyecto "Recursos", conecté el DI y nos fuimos.

Esto significa que solo dos proyectos (los "Recursos" y el "Nivel superior") se reconstruirán todas las veces, y si hago una compilación parcial (Shift-F6), entonces no se reconstruirán en absoluto.

Una vez más, no fue un gran trabajo, pero con 48 proyectos en construcción cada vez que una compilación demoraría unos 3 minutos, así que estaba perdiendo de 30 a 90 minutos por día con reconstrucciones innecesarias. Me tomó un tiempo para refactorizar, pero creo que fue una buena inversión.

Aquí hay un diagrama simplificado. Tenga en cuenta que las dependencias de Main.exe a Proj1 y Proj2 no se muestran para reducir el desorden.

Con este diseño, puedo hacer una compilación de Proj1 o Proj2 sin activar una reconstrucción completa, ya que no tienen ninguna dependencia en una sección de Resources . Solo Main conoce la implementación de Resources .

Answer 11

Tuve el mismo problema en VS 2015.

¿Cuál fue el truco para mí?

1. Un proyecto se refería a sí mismo copiar en algún otro contenedor de proyecto (magia, sí). Este tipo de cosas se pueden encontrar al cambiar a producción de desarrollo de diagnóstico (en opciones de compilación) y luego intentar construir proyectos uno por uno desde la parte superior de la jerarquía de proyectos: si ve el proyecto que se reconstruye incluso si no se ha cambiado nada, vea su referencias.
2. Cambié todos los archivos de "copiar siempre" en todos los proyectos para "copiar si es más nuevo". Básicamente, en todos los archivos .csproj, reemplace <CopyToOutputDirectory>Always</CopyToOutputDirectory> por <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
3. Luego deshabilité el túnel NTFS como se describe en this artículo con este script de powershell:

New-ItemProperty "HKLM:/SYSTEM/CurrentControlSet/Control/FileSystem" -Name "MaximumTunnelEntries" -Value 0 -PropertyType "DWord"

Después de eso necesitaba reconstruir y parece que funciona por ahora.

Answer 12

Tuve el problema de los proyectos de reconstrucción de Visual Studio al actualizar de Visual Studio 2015 a 2017 y agregué esta respuesta para el beneficio de aquellos que podrían experimentar problemas similares, ya que no parece estar documentado en ninguna parte.

En mi caso, el problema era que todos los proyectos en la solución tenían la misma ruta de salida intermedia (obj). El archivo GeneratedInternalTypeHelper.cs se genera en todos los proyectos que contienen XAML. Hasta Visual Studio 2015, aparentemente el proceso de compilación no verificó la fecha de archivo de este archivo y, por lo tanto, no ocurrió ningún problema. Con VS2017, la fecha del archivo de este archivo está marcada y, debido a que un proyecto posterior en el proceso de compilación lo sobreescribirá (con el mismo contenido), el proyecto anterior volverá a compilarse, reactivando la compilación posterior, ad infinitum.

La solución en este caso es garantizar que todos los proyectos tengan directorios de salida intermedios diferentes, lo que hará que el problema desaparezca.

Answer 13

Tuve los mismos problemas contigo. Descubrí que provenía de algunos archivos eliminados. Cuando eliminé los archivos de mi proyecto, los problemas desaparecieron. Saludos.