[visual-studio] Visual Studio 2010 siempre piensa que el proyecto está desactualizado, pero nada ha cambiado


12 Answers

En Visual Studio 2012 pude lograr el mismo resultado más fácilmente que en la solución aceptada.

Cambié la opción en el menú HerramientasOpcionesProyectos y SolucionesCrear y Ejecutar → * Verbosidad de salida de compilación del proyecto MSBuild "de Mínimo a Diagnóstico .

Luego, en el resultado de compilación encontré las mismas líneas buscando "no actualizado":

El proyecto 'blabla' no está actualizado. El elemento del proyecto 'c: \ foo \ bar.xml' tiene el atributo 'Copiar en directorio de salida' establecido en 'Copiar siempre'.

Question

Tengo un problema muy similar como se describe here .

También actualicé una solución mixta de proyectos de C ++ / CLI y C # de Visual Studio 2008 a Visual Studio 2010. Y ahora en Visual Studio 2010, un proyecto de C ++ / CLI siempre se queda sin fecha.

Incluso si se compiló y se vinculó justo antes y se golpea F5, aparece el mensaje "El proyecto está desactualizado. ¿Te gustaría construirlo?" aparece. Esto es muy molesto porque el archivo DLL tiene un nivel muy bajo y obliga a reconstruir casi todos los proyectos de la solución.

Mis configuraciones pdb están configuradas en el valor predeterminado ( here ).

¿Es posible obtener la razón por la cual Visual Studio 2010 obliga a una reconstrucción o piensa que un proyecto está actualizado?

¿Alguna otra idea de por qué Visual Studio 2010 se comporta así?




Para mí fue la presencia de un archivo de encabezado no existente en "Archivos de encabezado" dentro del proyecto. Después de eliminar esta entrada (clic con el botón derecho> Excluir del proyecto) compilada por primera vez, luego directamente

========== Build: 0 exitoso, 0 fallido, 5 actualizado, 0 omitido ==========

y no se hizo ningún intento de reconstrucción sin modificación. Creo que es un check-before-build implementado por VS2010 (no estoy seguro si documentado, podría serlo) que activa el indicador "AlwaysCreate".




La mayoría de los sistemas de compilación usan marcas de tiempo de datos para determinar cuándo deberían producirse las reconstrucciones: la marca de fecha / hora de los archivos de salida se compara con la última hora modificada de las dependencias; si alguna de las dependencias es más reciente, el objetivo se reconstruye.

Esto puede causar problemas si alguna de las dependencias obtiene de alguna manera una marca de tiempo de datos no válida, ya que es difícil para la marca de tiempo de cualquier salida de compilación exceder alguna vez la marca de tiempo de un archivo supuestamente creado en el futuro: P




He eliminado un cpp y algunos archivos de encabezado de la solución (y del disco) pero todavía tenía el problema.

La cosa es que cada archivo que usa el compilador va en un archivo * .tlog en su directorio temporal. Cuando elimina un archivo, este archivo * .tlog no se actualiza. Ese es el archivo utilizado por las compilaciones incrementales para verificar si su proyecto está actualizado.

Edite este archivo .tlog manualmente o limpie su proyecto y vuelva a generarlo.




Tuve este problema en VS2013 (Actualización 5) y puede haber dos razones para eso, que puede encontrar habilitando la salida de compilación "Detallada" en "Herramientas" -> "Proyectos y soluciones" -> "Generar y ejecutar" .

  1. "Forcing recompile of all source files due to missing PDB "..."
    Esto sucede cuando deshabilita la salida de información de depuración en sus opciones de compilación (en Configuración del proyecto: "C / C ++" -> "Formato de información de depuración" a "Ninguno" y "Vinculador" -> "Generar información de depuración" a "No":) . Si ha dejado "C / C ++" -> "Nombre de archivo de base de datos de programa" en el valor predeterminado (que es "$ (IntDir) vc $ (PlatformToolsetVersion) .pdb"), VS no encontrará el archivo debido a un error ( https://connect.microsoft.com/VisualStudio/feedback/details/833494/project-with-debug-information-disabled-always-rebuilds ).
    Para solucionarlo, simplemente borre el nombre del archivo en "" (campo vacío).

  2. "Forcing rebuild of all source files due to a change in the command line since the last build."
    Esto también parece ser un error conocido de VS ( https://connect.microsoft.com/VisualStudio/feedback/details/833943/forcing-rebuild-of-all-source-files-due-to-a-change-in-the-command-line-since-the-last-build ) y parece estar corregido en las versiones más nuevas (pero no en VS2013). No sé de ninguna solución, pero si lo hace, de todos modos, publíquela aquí.




Otro en Visual Studio 2015 SP3, pero me encontré con un problema similar en Visual Studio 2013 hace unos años.

Mi problema era que de alguna forma se usaba un archivo cpp incorrecto para los encabezados precompilados (así que tenía dos archivos cpp que creaban los encabezados precompilados). Ahora, ¿por qué Visual Studio cambió los indicadores en el cpp incorrecto para 'crear encabezados precompilados' sin mi pedido? No tengo ni idea, pero sucedió ... ¿tal vez algún complemento o algo?

De todos modos, el archivo cpp incorrecto incluye el archivo version.h que se cambia en cada compilación. Así que Visual Studio reconstruye todos los encabezados y por eso todo el proyecto.

Bueno, ahora ha vuelto al comportamiento normal.




Si cambia los argumentos del Comando de depuración para el proyecto, esto también desencadenará que el proyecto necesite ser reconstruido. Aunque el objetivo en sí mismo no se ve afectado por los argumentos de depuración, las propiedades del proyecto han cambiado. Sin embargo, si reconstruyes, el mensaje debería desaparecer.




Existen bastantes razones posibles y, como se señaló, primero debe diagnosticarlas configurando MSBuild como 'Diagnóstico'. La mayoría de las veces, la razón indicada se explicaría por sí misma y usted podría actuar de inmediato, 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. Aquí está en más palabras.




También nos encontramos con este problema y descubrimos cómo resolverlo.

El problema fue como se indicó anteriormente "El archivo ya no existe en el disco".

Esto no es muy correcto. El archivo existe en el disco, pero el archivo .VCPROJ hace referencia al archivo en otro lugar.

Puede 'descubrir' esto yendo a la "vista de archivo incluido" y haciendo clic en cada archivo de inclusión sucesivamente hasta que encuentre el que Visual Studio no puede encontrar. A continuación, AGREGUE ese archivo (como un elemento existente) y elimine la referencia que no se puede encontrar y todo está bien.

Una pregunta válida es: ¿cómo puede Visual Studio incluso crear si no sabe dónde están los archivos incluidos?

Creemos que el archivo .vcproj tiene alguna ruta relativa al archivo ofensivo en algún lugar que no se muestra en la GUI de Visual Studio, y esto explica por qué el proyecto realmente se compilará aunque la vista en árbol de las inclusiones sea incorrecta.




Tuve un problema similar y seguí las instrucciones anteriores (la respuesta aceptada) para localizar los archivos faltantes, pero no sin rascarme la cabeza. Aquí está mi resumen de lo que hice. Para ser precisos, estos archivos no faltan, ya que el proyecto no los requiere para su compilación (al menos en mi caso), pero son referencias a archivos que no existen en el disco y que realmente no son necesarios.

Aquí está mi historia:

  1. En Windows 7, el archivo se encuentra en %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\% . Hay dos archivos similares devenv.exe.config.config y devenv.exe.config . Quieres cambiar más adelante uno.

  2. En Windows 7, no tiene permiso para editar este archivo en archivos de programa. Solo cópielo en otro lugar (escritorio) y cámbielo a la ubicación de los archivos del programa.

  3. Estaba intentando descubrir cómo conectar DebugView al IDE para ver los archivos que faltan. Bueno, no tienes que hacer nada. Simplemente ejecútelo y capturará todos los mensajes. Asegúrese de que la opción del menú Capture Events esté seleccionada en el menú Capture , que por defecto debería seleccionarse.

  4. DebugView NO mostrará todos los archivos que faltan a la vez (¡al menos no lo hizo para mí)! Debería ejecutar DebugView y ejecutar el proyecto en Visual Studio 2010. Indicará el mensaje project out of date del project out of date , seleccionará para compilar y DebugView mostrará el primer archivo que falta o está causando la reconstrucción. Abra el archivo de proyecto (no el archivo de solución) en el Bloc de notas y busque ese archivo y elimínelo. Es mejor cerrar el proyecto y volver a abrirlo mientras se hace esta eliminación. Repita este proceso hasta que DebugView ya no muestre los archivos que faltan.

  5. Es útil configurar el filtro de mensajes para que no esté actualizado desde el botón de la barra de herramientas de DebugView o la opción EditarFiltro / Resaltar . De esta forma, los únicos mensajes que muestra son los que tienen cadenas `no actualizadas '.

Tenía muchos archivos que eran referencias innecesarias y al eliminarlos todos corrigieron el problema siguiendo los pasos anteriores.

Segunda forma de encontrar todos los archivos que faltan a la vez

Hay una segunda forma de encontrar estos archivos a la vez, pero implica (a) control de fuente e (b) integración con Visual Studio 2010. Usando Visual Studio 2010 , agregue su proyecto a la ubicación deseada o a la ubicación ficticia en la fuente controlar. Intentará agregar todos los archivos, incluidos los que no existen en el disco, pero a los que se hace referencia en el archivo del proyecto. Vaya a su software de control de fuente como Perforce , y debería marcar estos archivos que no existen en el disco en un esquema de color diferente. Perforce les muestra con un candado negro. Estas son tus referencias faltantes. Ahora tiene una lista de todas ellas, y puede eliminarlas todas de su archivo de proyecto usando el Bloc de notas y su proyecto no se quejaría de estar desactualizado .




En mi caso, uno de los proyectos contiene múltiples archivos IDL. El compilador MIDL genera un archivo de datos DLL llamado 'dlldata.c' para cada uno de ellos, independientemente del nombre del archivo IDL. Esto hizo que Visual Studio compilara los archivos IDL en cada compilación, incluso sin cambios en ninguno de los archivos IDL.

La solución consiste en configurar un archivo de salida único para cada archivo IDL (el compilador MIDL siempre genera dicho archivo, incluso si se omite el modificador / dlldata):

  • Haga clic con el botón derecho en el archivo IDL
  • Seleccionar propiedades - MIDL - Salida
  • Ingrese un nombre de archivo exclusivo para la propiedad Archivo DllData



Otra solución simple referenciada por Visual Studio Forum .

Cambio de configuración: menú HerramientasOpcionesProyectos y solucionesConfiguración de proyectos de VC ++Modo de Explorador de soluciones para mostrar todos los archivos .

Luego puede ver todos los archivos en Solution Explorer.

Busque los archivos marcados con el icono amarillo y elimínelos del proyecto.

Está bien.




Estoy usando Visual Studio 2013 Professional con la Actualización 4, pero no encontré resolución con ninguna de las otras sugerencias, sin embargo, logré resolver el problema para mi proyecto de equipo.

Esto es lo que hice para causar el problema:

  • Creado un nuevo objeto de clase (Proyecto -> Agregar clase)
  • Cambié el nombre del archivo a través del Explorador de soluciones y hice clic en Sí cuando me preguntaron si quería cambiar automáticamente el nombre de todas las referencias para que coincidan.

Esto es lo que hice para resolver el problema:

  • Ir a Team Explorer Home
  • Haga clic en Source Control Explorer
  • Explore en la carpeta donde están todos los archivos de clase / proyecto
  • Encontré el nombre de archivo ORIGINAL en la lista y lo eliminé haciendo clic con el botón derecho.
  • Construir

Si este es el caso para usted, asegúrese de eliminar el archivo fantasma en lugar del que desea conservar en el proyecto.






Related