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

Tengo un problema muy similar al descrito aquí .

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

Incluso si se ha compilado y vinculado justo antes y F5se acierta, el cuadro de mensaje "El proyecto está desactualizado. ¿Desea construirlo?" aparece. Esto es muy molesto porque el archivo DLL tiene niveles muy bajos y obliga a reconstruir casi todos los proyectos de la solución.

Mi configuración de pdb está establecida en el valor predeterminado ( solución sugerida para este problema ).

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

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

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 Habilitar el registro del sistema de proyecto C ++ para habilitar el registro de depuración en Visual Studio y dejar que le diga qué está causando la reconstrucción:

1. Abra el devenv.exe.configarchivo (encontrado en %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\o en %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\). Para las versiones Express, se nombra el archivo de configuración V*Express.exe.config.

2. Agregue lo siguiente después de la </configSections>línea:

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

3. Reiniciar Visual Studio
4. Abra DbgView y asegúrese de que esté capturando la salida de depuración
5. Intenta depurar (presiona F5 en Visual Studio)

6. Busque en el registro de depuración cualquier línea del formulario:

   Información devenv.exe: 0: El proyecto 'Bla \ Bla \ Dummy.vcxproj' no está actualizado porque falta la entrada de compilación 'Bla \ Bla \ SomeFile.h'.

   (Simplemente presioné Ctrl + F y busqué not up to date) Estas serán las referencias que harán que el proyecto esté "desactualizado" perpetuamente.

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>

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 → Compilar y ejecutar → * Verbosidad de salida de compilación del proyecto MSBuild "de Mínimo a Diagnóstico .

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

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

Esto me pasó a mí hoy. Pude rastrear 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.

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 de inclusión" y haciendo clic en cada archivo de inclusión a su vez hasta que encuentre el que Visual Studio no puede encontrar. Luego AGREGAS ese archivo (como un elemento existente) y borras la referencia que no se puede encontrar y todo está bien.

Una pregunta válida es: ¿Cómo puede Visual Studio incluso construir si no sabe dónde están los archivos de inclusión?

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 construirá a pesar de que la vista en árbol de las inclusiones es incorrecta.

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 comenzar a trabajar. Sin embargo, tuve que lidiar con una gran cantidad de encabezados de mala inclusión. Con la salida de depuración detallada, la eliminación de uno provocó que el IDE se congelara durante 30 segundos mientras generaba la descarga de depuración, lo que hizo que el proceso fuera muy lento.

Me impaciente y escribí un script de Python rápido y sucio para verificar los archivos del proyecto (Visual Studio 2010) y generar todos los archivos que faltan a la vez, junto con los filtros en los que están ubicados. Puede encontrarlo como un Gist aquí: https://gist.github.com/antiuniverse/3825678 (o esta bifurcación 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 + ")")

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

La cosa es que cada archivo que utiliza 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 reconstruya.

Tuve un problema similar, pero en mi caso no faltaron archivos, hubo un error en la forma en que se definió el archivo de salida pdb: olvidé el sufijo .pdb (descubrí el truco de registro de depuración).

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

<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>

a

<ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>

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" -> "Compilar 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 las opciones del compilador (en la configuración del proyecto: „C / C ++“ -> “Formato de información de depuración“ a „Ninguno“ y „Linker“ -> “Generar información de depuración“ a „No“:) . Si ha dejado "C / C ++" -> "Nombre del archivo de la base de datos del 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 a "" (campo vacío).

2. "Forcing rebuild of all source files due to a change in the command line since the last build."
   Esto parece ser un error VS conocido también ( 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 arreglado en versiones más recientes (pero no VS2013). No conozco ninguna solución, pero si lo haces, publícalo aquí.

No sé si alguien más tiene este mismo problema, pero las propiedades de mi proyecto se habían "Configuration Properties" -> C/C++ -> "Debug Information Format"establecido en "Ninguno", y cuando lo cambié a la "Base de datos del programa (/ Zi)" predeterminada, eso impidió que el proyecto se volviera a compilar cada vez. .

Otra solución simple referenciada por Visual Studio Forum .

Cambio de configuración: menú Herramientas → Opciones → Proyectos y soluciones → Configuración del proyecto VC ++ → Modo Explorador de soluciones para mostrar todos los archivos .

Luego puede ver todos los archivos en el Explorador de soluciones.

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

Está bien.

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

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

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

Nuevamente, el proyecto que informaba el problema no era el proyecto problemático. Intente configurar todos los proyectos en "Base de datos del programa (/ Zi)" para solucionar el problema.

Encontré este problema hoy, sin embargo, fue un poco diferente. Tuve un proyecto DLL CUDA en mi solución. Compilar en una solución limpia estuvo bien, pero por lo demás falló y el compilador siempre trató el proyecto CUDA DLL como no actualizado.

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

Pero no falta ningún archivo de encabezado en mi solución. Entonces descubrí la razón en mi caso.

He cambiado el Directorio Intermedio del proyecto anteriormente, aunque no causó problemas. Y ahora, cuando cambié el Directorio Intermedio del Proyecto DLL CUDA nuevamente 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.

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 no son archivos que faltan, ya que el proyecto no los necesita para construir (al menos en mi caso), pero son referencias a archivos que no existen en el disco 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.configy devenv.exe.config. Quieres cambiar una más tarde.

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

3. Estaba tratando de 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 Capture Eventsopción de menú esté seleccionada en el Capturemenú que por defecto debería seleccionarse.

4. ¡DebugView NO mostrará todos los archivos que faltan a la vez (al menos no para mí)! Debería ejecutar DebugView y luego ejecutar el proyecto en Visual Studio 2010. Aparecerá el project out of datemensaje, seleccione Sí para compilar y DebugView mostrará el primer archivo que falta o está causando la reconstrucción. Abra el archivo del proyecto (no el archivo de la solución) en el Bloc de notas y busque ese archivo y elimínelo. Es mejor que cierre su proyecto y lo vuelva a abrir mientras realiza esta eliminación. Repita este proceso hasta que DebugView ya no muestre ningún archivo faltante.

5. Es útil configurar el filtro de mensajes para que no esté actualizado desde el botón de la barra de herramientas DebugView o la opción Editar → Filtro / Resaltar . De esa manera, los únicos mensajes que muestra son los que tienen una cadena `` no actualizada ''.

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

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

Hay una segunda forma de encontrar todos estos archivos a la vez, pero implica (a) control de origen y (b) integración de este con Visual Studio 2010. Con Visual Studio 2010 , agregue su proyecto a la ubicación deseada o ubicación ficticia en el origen controlar. Intentará agregar todos los archivos, incluidos los que no existen en el disco pero que se mencionan 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 los muestra con un candado negro en ellos. Estas son tus referencias faltantes. Ahora tiene una lista de todos ellos, y puede eliminarlos de su archivo de proyecto usando el Bloc de notas y su proyecto no se quejará por estar desactualizado .

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) se vuelve a compilar por primera vez, luego directamente

========== Compilación: 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 está documentado, podría estarlo) que activa el indicador "AlwaysCreate".

Si está utilizando el comando MSBuild de 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 MSBuild:

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

Como se documenta aquí (advertencia: verbosidad habitual de MSDN). Cuando termina la acumulación, buscar la cadena will be compileden el archivo de registro creado durante la construcción, MyLog.log.

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:

• Creó un nuevo objeto de clase (Proyecto -> Agregar clase)
• Cambié el nombre del archivo a través del Explorador de soluciones e hice clic en Sí cuando se me preguntó 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 la página de inicio de Team Explorer
• Haga clic en Explorador de control de origen
• Ir a la carpeta donde se encuentran 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, entonces asegúrese de que está eliminando el archivo fantasma en lugar del archivo real que desea mantener en el proyecto.

Tuve este problema y encontré esto:

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

Proyecto Visual C ++ continuamente desactualizado ( winwlm.h macwin32.h rpcerr.h macname1.hfalta)

Problema:

En Visual C ++ .Net 2003, uno de mis proyectos siempre afirmó estar desactualizado, aunque nada había cambiado y no se había informado ningún error en la última compilación.

Al abrir el archivo BuildLog.htm para el proyecto correspondiente, se 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 parece a esto:

  MyApplication : warning PRJ0041 : Cannot find missing dependency 'macwin32.h' for file 'MyApplication.rc'.  

Su proyecto aún puede compilarse, pero puede seguir apareciendo desactualizado hasta que se encuentre este archivo.

Solución:

Incluir en afxres.hlugar de resource.hdentro del archivo .rc del proyecto.

El archivo .rc del proyecto contenía "#include resource.h". Dado que el compilador de recursos no respeta los #ifdefbloques del preprocesador , lo destruirá e intentará encontrar los archivos de inclusión que debería ignorar. Windows.h contiene muchos de esos bloques. Incluyendo afxres.h en su lugar arregló las advertencias PRJ0041 y eliminó el cuadro de diálogo de error "El proyecto está 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 provocó 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 derecho en el archivo IDL
• Seleccione Propiedades - MIDL - Salida
• Ingrese un nombre de archivo único para la propiedad DllData File

Pasé muchas horas arrancándome el pelo por esto. El resultado de la compilación no fue consistente; diferentes proyectos estarían "no actualizados" por diferentes razones de una compilación a la siguiente compilación consecutiva. Finalmente encontré que el culpable era DropBox (3.0.4). Junto mi carpeta de origen desde ... \ DropBox en mi carpeta de proyectos (no estoy seguro si esta es la razón), pero DropBox de alguna manera "toca" los archivos durante una compilación. Sincronización pausada y todo está constantemente actualizado.

Existen varias razones potenciales y, como se señaló, primero debe diagnosticarlas configurando la verbosidad de MSBuild en 'Diagnóstico'. La mayoría de las veces, la razón indicada se explica por sí misma y usted podría actuar de inmediato, PERO ocasionalmente MSBuild afirma erróneamente que algunos archivos se modifican y deben copiarse.

Si ese es el caso, deberá deshabilitar el túnel NTFS o duplicar su carpeta de salida en una nueva ubicación. Aquí está en más palabras.

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

¡Hora del sistema incorrecta en la configuración de arranque dual!

Resulta que mi arranque dual con Ubuntu fue la causa raíz. He sido demasiado flojo para arreglar Ubuntu y 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 la hora incorrecta del sistema, luego corrigí la hora. Como resultado, todos los archivos de compilación tenían marcas de tiempo incorrectas, y VS pensaría que todos están desactualizados y reconstruiría el proyecto.

La mayoría de los sistemas de compilación utilizan marcas de tiempo de datos para determinar cuándo deben ocurrir las reconstrucciones (la marca de fecha / hora de cualquier archivo de salida se compara con la última hora modificada de las dependencias), si alguna de las dependencias es más reciente, el destino se reconstruye.

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

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' establecido en 'Copy if newer'. La solución parecía ser cambiar la propiedad 'Copiar al directorio de salida' a 'No copiar'.

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

¡Es enormemente útil con las respuestas aquí que sugieren cómo hacer que msbuild derrame los granos sobre por qué sigue construyendo todo!

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

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 la reconstrucción de la solución.

Lo arreglé asegurándome de que el pdbarchivo de salida de C / C ++ y el enlazador coincidía con la ubicación utilizada por los otros proyectos de trabajo. También encendí RTTI.

Otro en Visual Studio 2015 SP3, pero he encontrado un problema similar en Visual Studio 2013 hace unos años.

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

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

Bueno, ahora ha vuelto al comportamiento normal.

Tenía un proyecto VC ++ que siempre estaba compilando todos los archivos y que otras personas habían actualizado previamente de VS2005 a VS2010. Descubrí que todos los archivos cpp en el proyecto, excepto StdAfx.cpp, estaban configurados para crear (/ Yc) el encabezado precompilado. Cambié esto para que solo StdAfx.cpp estuviera configurado para crear el encabezado precompilado y el resto estaba configurado para Usar (/ Yu) el encabezado precompilado y esto solucionó el problema para mí.

Estoy en Visual Studio 2013 y acabo de actualizarme a la actualización de Windows 10 de mayo de 2019 y la compilación de repente tuvo que rehacerse cada vez, independientemente de los cambios. Intenté cambiar el nombre del pch a ProjectName en lugar de TargetName, busqué los archivos faltantes con el registro detallado y ese script de Python, pero al final fue mi tiempo que no se sincronizó con los servidores de MS (por milisegundos).

Lo que resolvió esto para mí fue

• "Ajustar fecha y hora" en el panel de control
• "Sincronizar ahora"

Ahora mis proyectos no necesitan ser recompilados sin ninguna razón.

Creo que ha colocado una nueva línea u otro espacio en blanco. Retíralo y presiona F5 nuevamente.

Los proyectos .NET siempre se vuelven a compilar 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.