Подтвердить что ты не робот

Предупреждение Visual Studio о копиях файлов с различным содержимым

Когда я перехожу к отладке моего проекта С++ в Visual Studio, появляется всплывающее окно с предупреждением об ошибке:

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.

У меня возникли проблемы с пониманием того, что это даже пытается сказать мне, не говоря уже о том, как это исправить. Сначала я подумал, что может быть жалуется, что я случайно продублировал файл в каталоге, который я проверил, и не нашел ничего подобного, что оставляет меня в тупике. Я также попытался исключить файл из решения и снова добавить его, что также не устранило проблему.

Предупреждение, по-видимому, не мешает разработке моего проекта, но я полагаю, что предупреждения существуют по какой-то причине, поэтому, если кто-то знает, что пошло не так, любые советы будут очень признательны. Насколько я знаю, я ничего не изменил, чтобы сообщение появилось, оно только что появилось, когда я отправился отлаживать решение и продолжал появляться с тех пор.

Кроме того, появилось больше копий одного и того же предупреждения, относящихся к другим файлам заголовка в моем решении (я еще не получил о файлах .cpp, но это может быть совпадением, поскольку оно происходит только около 20 минут).

4b9b3361

Ответ 1

Попробуйте удалить контрольные точки из файла, о котором идет речь. Это сработало для меня, когда это произошло с Visual Studio 2013 для файла заголовка в сборке отладки. Источник: проблема с синхронизацией файла режима выпуска - текущий исходный код отличается от построенной версии

Дополнительные примечания: Clean/Rebuild также работает, но это болезненно для регулярного изменения кода. Включение точки останова после запуска отладчика просто задерживает сообщение.

Ответ 2

Проблема заключается в том, что отладчик считает, что контрольная сумма исходного файла отличается от того, что вычислял и размещал компилятор. Отладчик затем откажется применять точки останова в файлах, которые неправильно совпадают, чтобы вы не могли видеть данные, которые он не может гарантировать.

У меня это продолжалось, даже после чистой перестройки. Это с VS 2015. Мое предположение, возможно, является отладчиком, и компилятор не согласен с тем, как хешировать новые строки или что-то в этом роде? Исправление состоит в том, чтобы отключить "требовать, чтобы исходные файлы соответствовали исходной версии" в Debug → Options → Debugging → General

Ответ 3

Я решил это:

  • Закройте окно файла .h в Visual Studio, если оно открыто.
  • Закрыть Visual Studio.
  • Сбросьте файл .h из его обычного местоположения и вставьте его во временную папку, о которой не знает VS.
  • Перезапустите VS и скомпилируйте. Он будет жаловаться на отсутствующий файл .h. Хорошо - сделайте этого ублюдка попроси его!
  • Вставьте файл .h обратно в исходное местоположение.
  • Compile. VS с благодарностью примет недостающий файл. (Черт, я ненавижу Microsoft!)

Ответ 4

Не могли бы вы отлаживать другой исполняемый файл (а не тот, который действительно был создан?). Это обычная проблема в сценариях, где Visual Studio создает двоичные файлы в одном каталоге, но затем они копируются в другой каталог для отладки. Я бы посоветовал вам сравнить целевой путь по параметрам отладки и директорию вывода в общих настройках в Visual Studio.

TargetPath

Это объясняет проблему, поскольку вы на самом деле отлаживаете более старую версию двоичного файла (а не тот, который был создан в настоящее время) и, следовательно, предупреждение, так как Visual Studio не может найти версию исходных файлов для этой версии двоичный.

Ответ 5

Причиной могут быть зависимости от круговых заголовков. datum.h может включать another_header.h(прямо или косвенно), который включает в себя datum.h.

Ответ 6

это сработало для меня:

  • закрыть VS
  • удалить *.vcxproj.filters файл
  • перезапустить VS

проблема не должна быть.

Ответ 7

это сработало для меня:

  • чистый проект
  • Отладка/удаление всех контрольных точек:)

Ответ 8

Я вижу, что истинная причина этого вопроса не решена. Так что для кого-то, все еще ищущего, вот оно...    Наиболее распространенной причиной этой проблемы является то, что исходные файлы, используемые для создания существующих файлов obj, отличаются от существующих. Другими словами, конкретный проект не строился после новых модификаций источника. Решение этой проблемы заключается в том, чтобы восстановить проект после изменения.    Это случилось со мной в ситуации, когда я изменил свои файлы статических файлов библиотек, а затем, не создавая этот проект, начал свой проект приложения, который использовал этот проект статической библиотеки.