visual-studio - tag - visual studio code español

Visual Studio 2010 siempre piensa que el proyecto está desactualizado, pero nada ha cambiado (27)

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í?

Conocí este problema hoy, sin embargo, fue un poco diferente. Tenía un proyecto CUDA DLL en mi solución. La compilación en una solución limpia estaba bien, pero de lo contrario falló y el compilador siempre trató el proyecto DLL de CUDA como no actualizado.

Intenté la solución de esta publicación .

Pero no hay ningún archivo de encabezado perdido en mi solución. Entonces descubrí el motivo en mi caso.

He cambiado el Directorio intermedio del proyecto anteriormente, aunque no causó problemas. Y ahora, cuando cambié el Directorio Intermedio del Proyecto CUDA DLL de nuevo a $ (Configuración) /, todo vuelve a funcionar bien.

Supongo que hay un pequeño problema entre CUDA Build Customization y el directorio intermedio no predeterminado.

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ú Herramientas → Opciones → Proyectos y Soluciones → Crear 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''.

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

Esto me pasó hoy. Pude localizar la causa: el proyecto incluía un archivo de encabezado que ya no existía en el disco.

Eliminar el archivo del proyecto resolvió el problema.

Esto me pasó varias veces y luego me fui, antes de que pudiera entender por qué. En mi caso fue:

¡Tiempo de sistema incorrecto en la configuración de inicio dual!

Resulta que mi arranque dual con Ubuntu fue la causa raíz. He sido demasiado flojo para arreglar Ubuntu para dejar de jugar con mi reloj de hardware. Cuando inicio sesión en Ubuntu, el tiempo salta 5 horas hacia adelante.

Por mala suerte, construí el proyecto una vez, con el tiempo del sistema equivocado, luego corregí el tiempo. Como resultado, todos los archivos de compilación tenían marcas de tiempo incorrectas, y VS pensaría que estaban desactualizados y reconstruirían el proyecto.

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.

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.

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.

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

La respuesta aceptada me ayudó en el camino correcto para descubrir cómo resolver este problema para el proyecto jodido con el que tuve que empezar a trabajar. Sin embargo, tuve que lidiar con una gran cantidad de encabezados de inclusión malos. Con la salida de depuración verbosa, la eliminación de uno provocó que el IDE se congelara durante 30 segundos mientras emitía speug debug, lo que hizo que el proceso fuera muy lento.

Me impacienté y escribí un script de Python rápido y sucio para verificar los archivos del proyecto (Visual Studio 2010) y emitir todos los archivos que faltan a la vez, junto con los filtros en los que están ubicados. Puedes encontrarlo como un Gist aquí: https://gist.github.com/antiuniverse/3825678 (o este fork que admite rutas relativas )

Ejemplo:

D:/...> check_inc.py sdk/src/game/client/swarm_sdk_client.vcxproj [Header Files]: fx_cs_blood.h (cstrike/fx_cs_blood.h) hud_radar.h (cstrike/hud_radar.h) [Game Shared Header Files]: basecsgrenade_projectile.h (../shared/cstrike/basecsgrenade_projectile.h) fx_cs_shared.h (../shared/cstrike/fx_cs_shared.h) weapon_flashbang.h (../shared/cstrike/weapon_flashbang.h) weapon_hegrenade.h (../shared/cstrike/weapon_hegrenade.h) weapon_ifmsteadycam.h (../shared/weapon_ifmsteadycam.h) [Source Files/Swarm/GameUI - Embedded/Base GameUI/Headers]: basepaenl.h (swarm/gameui/basepaenl.h) ...

Código fuente:

#!/c/Python32/python.exe import sys import os import os.path import xml.etree.ElementTree as ET ns = ''{http://schemas.microsoft.com/developer/msbuild/2003}'' #Works with relative path also projectFileName = sys.argv[1] if not os.path.isabs(projectFileName): projectFileName = os.path.join(os.getcwd(), projectFileName) filterTree = ET.parse(projectFileName+".filters") filterRoot = filterTree.getroot() filterDict = dict() missingDict = dict() for inc in filterRoot.iter(ns+''ClInclude''): incFileRel = inc.get(''Include'') incFilter = inc.find(ns+''Filter'') if incFileRel != None and incFilter != None: filterDict[incFileRel] = incFilter.text if incFilter.text not in missingDict: missingDict[incFilter.text] = [] projTree = ET.parse(projectFileName) projRoot = projTree.getroot() for inc in projRoot.iter(ns+''ClInclude''): incFileRel = inc.get(''Include'') if incFileRel != None: incFile = os.path.abspath(os.path.join(os.path.dirname(projectFileName), incFileRel)) if not os.path.exists(incFile): missingDict[filterDict[incFileRel]].append(incFileRel) for (missingGroup, missingList) in missingDict.items(): if len(missingList) > 0: print("["+missingGroup+"]:") for missing in missingList: print(" " + os.path.basename(missing) + " (" + missing + ")")

Los proyectos .NET siempre se recompilan independientemente. Parte de esto es mantener el IDE actualizado (como IntelliSense). Recuerdo haber hecho esta pregunta en un foro de Microsoft hace años, y esta fue la respuesta que me dieron.

No sé si alguien más tiene el mismo problema, pero las propiedades de mi proyecto tenían "Configuration Properties" -> C/C++ -> "Debug Information Format" establecido en "Ninguno", y cuando lo cambié de nuevo al valor predeterminado " Base de datos del programa (/ Zi) ", que impedía que el proyecto volviera a compilarse cada vez.

Otra solución simple referenciada por Visual Studio Forum .

Cambio de configuración: menú Herramientas → Opciones → Proyectos y soluciones → Configuració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.

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.

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".

Para mí, el problema surgió en un proyecto de WPF donde algunos archivos tenían su propiedad ''Build Action'' establecida en ''Resource'' y su ''Copy to Output Directory'' en ''Copy if newer''. La solución parecía ser cambiar la propiedad ''Copiar a directorio de salida'' a ''No copiar''.

msbuild sabe que no debe copiar los archivos de ''Recursos'' a la salida, pero aún activa una compilación si no están allí. Tal vez eso podría considerarse un error?

Es muy útil con las respuestas aquí que sugieren cómo hacer que MSbuild explique por qué sigue construyendo todo.

Pasé muchas horas gastando mi cabello en esto. La salida de compilación no fue consistente; los diferentes proyectos "no estarían actualizados" por diferentes motivos, desde una construcción hasta la siguiente construcción consecutiva. Finalmente descubrí que el culpable era DropBox (3.0.4). Uniré mi carpeta de origen de ... / DropBox a la carpeta de proyectos (no estoy seguro de si este es el motivo), pero Dropbox de alguna manera "toca" los archivos durante una compilación. Pausó la sincronización y todo está constantemente actualizado.

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.

Si está utilizando el comando MSBuild de la línea de comando (no el IDE de Visual Studio), por ejemplo, si está apuntando a AppVeyor o simplemente prefiere la línea de comando, puede agregar esta opción a su línea de comando de MSBuild:

/fileLoggerParameters:LogFile=MyLog.log;Append;Verbosity=diagnostic;Encoding=UTF-8

Como se documenta here (advertencia: nivel de detalle habitual de MSDN). Cuando finaliza la construcción, la búsqueda de la cadena will be compiled en el archivo de registro creado durante la compilación, MyLog.log .

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 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" .

"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).
"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í.

Tuve este problema y encontré esto:

http://curlybrace.blogspot.com/2005/11/visual-c-project-continually-out-of.html

Proyecto de Visual C ++ continuamente desactualizado ( winwlm.h macwin32.h rpcerr.h macname1.h falta)
Problema:
En Visual C ++ .Net 2003, uno de mis proyectos siempre decía que estaba desactualizado, aunque nada había cambiado y no se habían informado errores en la última compilación.
La apertura del archivo BuildLog.htm para el proyecto correspondiente mostró una lista de errores PRJ0041 para estos archivos, ninguno de los cuales aparece en mi sistema en ninguna parte: winwlm.h macwin32.h rpcerr.h macname1.h
Cada error se ve así:
MyApplication : warning PRJ0041 : Cannot find missing dependency ''macwin32.h'' for file ''MyApplication.rc''.
Su proyecto aún puede compilarse, pero puede seguir desactualizándose hasta que se encuentre este archivo.
Solución:
Incluya afxres.h lugar de resource.h dentro del archivo .rc del proyecto.
El archivo .rc del proyecto contenía "#include resource.h". Dado que el compilador de recursos no #ifdef bloques #ifdef preprocesador, se abrirá paso y tratará de encontrar archivos de inclusión que debería ignorar. Windows.h contiene muchos de esos bloques. Incluir afxres.h en su lugar arregló las advertencias PRJ0041 y eliminó el cuadro de diálogo de error "El proyecto está desactualizado".

Tuve un problema similar con Visual Studio 2005, y mi solución consistió en cinco proyectos en la siguiente dependencia (primero construida en la parte superior):

Video_Codec depends on nothing Generic_Graphics depends on Video_Codec SpecificAPI_Graphics depends on Generic_Graphics Engine depends on Specific_Graphics Application depends on Engine.

Estaba descubriendo que el proyecto Video_Codec quería una compilación completa incluso después de una limpieza completa y luego volver a generar la solución.

Lo solucioné asegurando que el archivo de salida pdb del C / C ++ y el vinculador coincidieran con la ubicación utilizada por los otros proyectos en funcionamiento. También conecté RTTI.

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:

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.
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.
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.
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á Sí 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.
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 Editar → Filtro / 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 .

Tuve un problema similar, pero en mi caso no había archivos faltantes, había un error en cómo se definió el archivo de salida pdb: Olvidé el sufijo .pdb (me enteré con el truco de registro de depuración).

Para resolver el problema, modifiqué, en el archivo vxproj, la siguiente línea:

<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>

<ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>

Visual Studio 2013 - "Forzar la recompilación de todos los archivos fuente debido a la falta de PDB". Intenté la salida de compilación detallada para localizar el problema: habilité la salida de compilación "Detallada" en "Herramientas" → "Proyectos y soluciones" → "Generar y ejecutar".

Tenía varios proyectos, todos C ++, configuré la opción para debajo de la configuración del proyecto: (C / C ++ → Formato de información de depuración) en la Base de datos del programa (/ Zi) para el proyecto problemático. Sin embargo, esto no detuvo el problema para ese proyecto. El problema provino de uno de los otros proyectos C ++ en la solución.

Establecí todos los proyectos de C ++ en "Base de datos de programa (/ Zi)". Esto solucionó el problema.

Nuevamente, el proyecto que reportó el problema no fue el problema. Intente configurar todos los proyectos en "Program Database (/ Zi)" para solucionar el problema.

Solo para Visual Studio / Express 2010. Ver otras respuestas (más fáciles) para VS2012, VS2013, etc.

Para encontrar los archivos que faltan , use la información del artículo Habilite el registro del sistema del proyecto de C ++ para habilitar el registro de depuración en Visual Studio y permita que solo le diga qué está causando la reconstrucción:

Abra el archivo devenv.exe.config (que se encuentra en %ProgramFiles%/Microsoft Visual Studio 10.0/Common7/IDE/ o en %ProgramFiles(x86)%/Microsoft Visual Studio 10.0/Common7/IDE/ ). Para las versiones Express, el archivo de configuración se llama V*Express.exe.config .
Agregue lo siguiente después de la línea </configSections> :
<system.diagnostics> <switches> <add name="CPS" value="4" /> </switches> </system.diagnostics>
Reiniciar Visual Studio
Abre DbgView y asegúrate de que está capturando la salida de depuración
Intenta depurar (pulsa F5 en Visual Studio)
Busque en el registro de depuración cualquier línea del formulario:
devenv.exe Información: 0: El proyecto ''Bla / Bla / Dummy.vcxproj'' no está actualizado porque falta la entrada de compilación ''Bla / Bla / SomeFile.h''.
(Solo presiono Ctrl + F y busqué not up to date ) Estas serán las referencias que harán que el proyecto esté perpetuamente "desactualizado".

Para corregir esto, elimine cualquier referencia a los archivos faltantes de su proyecto, o actualice las referencias para indicar sus ubicaciones reales.

Nota: si usa 2012 o posterior, el fragmento debe ser:

<system.diagnostics> <switches> <add name="CPS" value="Verbose" /> </switches> </system.diagnostics>