Advertencia de Visual Studio sobre copias de archivos con diferentes contenidos

8 minutos de lectura

Cuando voy a depurar mi proyecto C++ en Visual Studio, aparece un pequeño cuadro de diálogo de advertencia que me dice:

A copy of datum.h was found in
c:/users/brad/desktop/source/binary/datum.h, but the current
source code is different from the version built into
c:/users/brad/desktop/source/binary/datum.h.

Tengo problemas para entender lo que esto está tratando de decirme, y mucho menos cómo solucionarlo. Al principio pensé que podría estar quejándose de que accidentalmente había duplicado un archivo en el directorio, lo revisé y no encontré nada por el estilo, lo que me deja bastante perplejo. También intenté excluir el archivo de la solución y volver a agregarlo, lo que tampoco solucionó el problema.

La advertencia no parece obstaculizar el desarrollo de mi proyecto, pero supongo que las advertencias existen por una razón, por lo que si alguien sabe qué salió mal, cualquier consejo sería muy apreciado. Que yo sepa, no cambié nada para que apareciera el mensaje, solo apareció una vez que fui a depurar la solución y ha seguido apareciendo desde entonces.

Además, han comenzado a aparecer más copias de la misma advertencia, relacionadas con otros archivos de encabezado en mi solución (todavía no he recibido ninguno sobre archivos .cpp, pero podría ser una coincidencia, porque solo ha estado sucediendo durante aproximadamente 20 minutos).

  • Usted no está solo.

    – Daniel Daranas

    28 de abril de 2015 a las 8:12

  • Mmmm interesante. No encontré nada en Google. ¿Qué buscaste para encontrar eso?

    – brads3290

    28 de abril de 2015 a las 8:15

  • Los mensajes literales (omitiendo el archivo en particular y los nombres de las variables, por supuesto) suelen ser la mejor apuesta. En este caso busqué “pero el código fuente actual es diferente de la versión integrada”.

    – Daniel Daranas

    28 de abril de 2015 a las 8:48

  • Incluso hay dos resultados en este sitio, pero para encontrarlos es necesario omitir “pero”, porque los dos carteles no se molestaron en pegar el mensaje completo: 1, 2.

    – Daniel Daranas

    28 de abril de 2015 a las 8:51

  • En mi caso tenia multiples proyectos en la solucion y se me habia olvidado cambiar el Proyecto de inicio en el Explorador de soluciones antes de iniciar el nuevo archivo de proyecto desde el editor. Los dos proyectos tenían el mismo MainWindow clase (no se podía ver ninguna diferencia en la pantalla). VS estaba comparando el archivo en el editor (perteneciente al nuevo proyecto) con el almacenado en el proyecto anterior que todavía era el Proyecto de inicio y que fue el que realmente se lanzó.

    – minutos

    7 de noviembre de 2019 a las 14:21


avatar de usuario
greg

Intente eliminar los puntos de interrupción del archivo en cuestión. Esto funcionó para mí cuando ocurrió con Visual Studio 2013 para un archivo de encabezado en la compilación de depuración.
Fuente: Problema de sincronización de archivos en el modo de lanzamiento: el código fuente actual es diferente de la versión construida

Notas adicionales: Limpiar/Reconstruir también funciona, pero eso es doloroso para cambiar el código regularmente. Habilitar el punto de interrupción después de iniciar el depurador simplemente retrasa el mensaje.

  • Esto ha seguido ocurriendo incluso después de una reconstrucción limpia. Esto es con VS 2015. Supongo que quizás el depurador y el compilador no están de acuerdo sobre cómo codificar nuevas líneas o algo así. La solución es desactivar “requerir archivos de origen para que coincidan exactamente con la versión original” en Depuración -> Opciones -> Depuración -> General

    – Jon Watte

    04/07/2016 a las 17:00

  • Tenía puntos de interrupción en el archivo .H en el que estaba ladrando (establecidos en funciones en línea), ejecutando el depurador en VS2013. Eliminé los puntos de interrupción y el mensaje molesto ya no apareció.

    – David Carr

    22 de marzo de 2017 a las 1:39

  • eliminar todos los puntos de interrupción solucionó el problema para mí. Tenía uno en el archivo de encabezado que se marcaba. Gran consejo.

    – Edwinc

    19/09/2018 a las 19:29

  • Todo lo que esto hace es ocultar el problema, aún aparece, aún no podrá atravesarlo … -1

    – usuario541686

    1 de noviembre de 2020 a las 21:22


Lo resolví:

  1. Cierre la ventana del archivo .h en Visual Studio si está abierta.
  2. Cierre Visual Studio.
  3. CORTE el archivo .h de su ubicación normal y péguelo en una carpeta temporal que VS no conozca.
  4. Reinicie VS y compile. Se quejará del archivo .h que falta. Bien — ¡Haz que el bastardo lo pida!
  5. Pegue el archivo .h en su ubicación original.
  6. Compilar. VS aceptará con gratitud el archivo faltante. (¡Maldita sea, odio a Microsoft!)

  • Esto aún no evita que el problema vuelva a ocurrir (es decir, aún sucede la próxima vez que edite el archivo).

    – usuario541686

    1 de noviembre de 2020 a las 21:24


Esto ocurre si cambia el nombre de un archivo de implementación (*.c, *.cpp, etc.) a un archivo de encabezado.

Esto se debe a que el Tipo de artículo sigue siendo como C/C++ Source Filelo que hace que se compile como una unidad de traducción independiente en lugar de como un encabezado real, lo que impide que Visual Studio reconozca su inclusión como un encabezado en otro lugar.

Me tomó bastante tiempo darme cuenta de esto.

Para arreglar esto:

  1. Haga clic con el botón derecho en su archivo de encabezado en el Explorador de soluciones y seleccione Propiedades.

  2. Seleccione Todas las configuraciones, Todas las plataformas.

  3. En General, cambie Tipo de artículo a C/C++ Header.

  4. Presiona OK.

  5. Forzar la recompilación de cualquier archivo que #includees su encabezado (o simplemente Rebuild la solución).

El problema es que el depurador piensa que la suma de verificación del archivo fuente es diferente de lo que el compilador calculó y colocó allí. El depurador se negará a aplicar puntos de interrupción en los archivos que no coincidan, para evitar que vea datos que no puede garantizar que sean correctos.

Esto ha seguido ocurriendo incluso después de una reconstrucción limpia. Esto es con VS 2015. Supongo que quizás el depurador y el compilador no están de acuerdo sobre cómo codificar nuevas líneas o algo así. La solución es desactivar “requerir archivos de origen para que coincidan exactamente con la versión original” en Depuración -> Opciones -> Depuración -> General

avatar de usuario
Rodolfo Bundulis

¿Podría por casualidad estar depurando otro ejecutable (¿no el que realmente se creó?). Este es un problema común en escenarios en los que Visual Studio compila los archivos binarios en un directorio, pero luego se copian en otro directorio para su depuración. Le sugiero que compare la ruta de destino en la configuración de depuración y el directorio de salida en la configuración general de Visual Studio.

ruta de destino

Esto explicaría el problema, ya que en realidad está depurando una versión anterior del binario (no la que se creó actualmente) y, por lo tanto, la advertencia, ya que Visual Studio no puede encontrar la versión de los archivos fuente para esa versión del binario.

  • Logré hacer desaparecer la advertencia ejecutando la operación Limpiar en la solución. No estoy seguro de la semántica de la operación, así que imagino que habría hecho algo similar a lo que sugeriste. Gracias por la respuesta 🙂

    – brads3290

    28 de abril de 2015 a las 8:26

  • @BradSullivan bueno, si regresa, haga un comentario, podemos tratar de resolverlo 🙂 No hay muchas razones por las que pueda provenir.

    – Rodolfo Bundulis

    28 de abril de 2015 a las 8:39

  • Si esto no funciona para usted, ¡vea mi respuesta a continuación!

    – usuario541686

    1 de noviembre de 2020 a las 21:35

avatar de usuario
florecer256

El motivo puede ser dependencias de encabezado circular. datum.h puede incluir another_header.h (directa o indirectamente), que incluye datum.h.

  • Logré hacer desaparecer la advertencia ejecutando la operación Limpiar en la solución. No estoy seguro de la semántica de la operación, así que imagino que habría hecho algo similar a lo que sugeriste. Gracias por la respuesta 🙂

    – brads3290

    28 de abril de 2015 a las 8:26

  • @BradSullivan bueno, si regresa, haga un comentario, podemos intentar resolverlo 🙂 No hay muchas razones por las que pueda provenir.

    – Rodolfo Bundulis

    28 de abril de 2015 a las 8:39

  • Si esto no funciona para usted, ¡vea mi respuesta a continuación!

    – usuario541686

    1 de noviembre de 2020 a las 21:35

avatar de usuario
Esteban

Veo que la verdadera razón de esta pregunta no está respondida. Entonces, para alguien que todavía está buscando, aquí va… La razón más común de este problema es que los archivos fuente usados ​​para construir los archivos obj existentes son diferentes a los existentes. En otras palabras, el proyecto particular no se construyó después de nuevas modificaciones a la fuente. La solución a este problema es reconstruir el proyecto después de modificarlo. Esto me sucedió en una situación en la que había modificado mis archivos de proyectos de biblioteca estática y luego, sin construir ese proyecto, comencé mi proyecto de aplicación que estaba usando este proyecto de biblioteca estática.

¿Ha sido útil esta solución?