"В настоящий момент точка останова не будет удалена. Исходный код отличается от исходной версии". Что это значит?

Ответ 1

Как говорится, "исходный код отличается от исходной версии".

Щелкните правой кнопкой мыши папку проекта внутри проводника решений и выберите Clean. Создайте новую версию проекта, и точка останова будет работать снова!

Ответ 2

Если вы отменили проект DLL в конфигурации сборки Debug, ваш новый код никогда не будет создан!

Перейдите к Build --> Configuration Manager ... (в VS2010) и проверьте, проверен ли проект с кодом, который вы пытаетесь отладить, для текущей конфигурации сборки.

Ответ 3

Для меня это было во время работы над проектом WebSite. После очистки этих временных папок я получил правильные ошибки компилятора:

• C:\Documents and Settings\%username%\AppData\Local\Temp\Temporary ASP.NET Files
• C:\windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files

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

Ответ 4

Вы когда-нибудь делали это?

Вы хотите продолжить и запустить последнюю успешную сборку?

Если вы отметили поле и нажали "Да", вы получите последнюю успешную сборку, даже если ваш проект не компилируется. Это означает, что всякий раз, когда вы устанавливаете точку останова, вы получите эту ошибку.

Попробуйте изменить это значение:

• Инструменты
  • Параметры
    • Проекты и решения
      • Сборка и запуск
        • При запуске при возникновении ошибок сборки или развертывания: Не запускать

Ответ 5

Перейдите к

• Инструменты
  • Параметры
    • Debugging
      • Общие

Снимите флажок Требовать, чтобы исходные файлы соответствовали исходной версии

Ответ 6

Выберите Отладка в Конфигурация решений, а не Отпустить

Ответ 7

Обратите внимание на окно "Выход" в VS. Он расскажет вам, какие сборки загружены и когда. Вы можете увидеть, что загружается более старая версия вашей сборки где-то в папке.

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

Ответ 8

Закрытие Visual Studio и повторное открытие решения могут устранить проблему, то есть ошибку в самой IDE (я запускаю VS2010).

Если у вас несколько экземпляров Visual Studio, вам нужно только закрыть экземпляр, запускающий решение с проблемой.

Ответ 9

Новый способ решения этой проблемы появился в Visual Studio 2017 с 15.3.1 по 15.3.5. Если вы используете EditorConfig, опция charset=utf8 вызывает эти симптомы. Команда VS воспроизвела это и говорит, что работает над этим.

Итак, одно из исправлений - закомментировать строку charset=utf8 в файле .editorconfig.

Изменение: это должно быть исправлено с VS 15.5.

Ответ 10

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

Ответ 11

Для меня ни один из пунктов не решил проблему. Я просто добавил новую строку кода внутри этой функции, что-то вроде:

int a=0;

добавив, что, я думаю, я вызвал Visual Studio, чтобы добавить эту функцию в исходную версию

Ответ 12

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

• Обозреватель решений
  • щелкните правой кнопкой мыши Solution
    • Свойства
      • Общие свойства
        • Исходные файлы отладки
          • "Не ищите эти исходные файлы".

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

Ответ 13

Проблема заключается в том, что ваша информация об отладке не синхронизируется с вашей сборкой. Решение прост:

• Перейдите в папку с папкой
• Удалите файлы .pdb
• Перестроить

Сделайте трюк!

(странно, перестройка, не отбрасывающая файлы .pdb, не всегда работает. Я вижу обновленную дату обновления, но все же где-то в цепочке (отладчик VS2013, IIS, кеш сборки) это изменение не обнаружено)

Ответ 14

Это может произойти, когда системное время изменяется во время отладки или между сеансами отладки, будь то программно, вручную или внешней программой.

Ответ 15

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

Точка останова будет устранена после того, как активатор загрузит сборку (при условии, что символы сборки и отладки обновлены). Хорошее место для просмотра - это окно модулей в меню отладки. Там вы должны искать сборку, к которой принадлежит ваш файл. Сначала проверьте, что сборка загружена. Затем, откуда он загружен? Затем загружается файл символов. Опять же, где загружен файл символов? Наконец, проверьте версии обоих.

Ответ 16

Я тоже столкнулся с этим. Условия, которые вызвали мою проблему:

• Я запускаю полный экземпляр IIS7 локально
• Я запускаю свое программное обеспечение в отдельные проекты

Я вызвал это, открыв предыдущую версию (VS попросил спросить, хочу ли я указать на этот экземпляр в отладке IIS, я ответил "Да" ), затем открыв текущую версию (снова отвечая на запрос IIS "Да" ), затем попытка отладки в предыдущей версии.

Чтобы решить проблему, я просто закрыл и повторно открыл предыдущую и предполагаемую версию, еще раз подтвердив ее как источник отладки.

Ответ 17

Это происходит также при отладке проекта С++, который загружает модуль, который был реализован с помощью некоторого языка CRL (Managed С++, С# и т.д.). В этой ситуации сообщение об ошибке действительно вводит в заблуждение.

Решение состоит в том, чтобы включить свойство конфигурации среды выполнения Common CLR в проект запуска и перекомпилировать это.

Ответ 18

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

Ответ 19

Если у вас есть несколько проектов в вашем решении, убедитесь, что правильный проект установлен как StartUp Project. Чтобы настроить конкретный проект как проект запуска вашего решения, щелкните правой кнопкой мыши проект, выберите Set As StartUp Project.

После того, как я правильно установил проект StartUp, желаемый момент прерывания был достигнут потоком.

Ответ 20

идти к:

Сервис> Параметры> Отладка> Общие> не отмечено "Требовать, чтобы исходные файлы точно соответствовали исходной версии"

Ответ 21

Для меня решение было скрыто в Advanced Build Settings свойств проекта:

По неизвестной причине он был установлен в none: установка его на full заставила точки останова попасть.

Чтобы перейти в это диалоговое окно, откройте свойства проекта, затем перейдите к Build, затем нажмите кнопку Advanced... в нижней части страницы.

Ответ 22

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

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

Надеюсь это поможет..

Ответ 23

Что сработало для меня, так это изменить платформу решений от x86 до Any CPU. После перехода на Any, я установил адрес остановки, запустил веб-сайт, открыл страницу, нажал кнопку и остановился. Я закрыл сайт, сменил его на x86 и успешно выполнил ту же последовательность.

Ответ 24

В моем случае я присоединился к запущенному процессу в VS 2012. При подключении вам предоставляется возможность отладки в различных режимах (native, script, silverlight, managed 2.0, managed 4.0 и т.д.). По умолчанию отладчик автоматически выбирает режим. Однако Automatic не всегда делает правильный выбор. Если ваш процесс содержит несколько типов кода, убедитесь, что отладчик использует правильный.

Ответ 25

В моем случае я разрабатывал приложение Windows CE, которое протестировало против эмулятора. Проблема заключалась в том, что исполняемый файл не был размещен в эмуляторе, поэтому .pdb(в среде разработки) не синхронизировался с .exe(в эмуляторе), потому что новый .exe никогда не копировался в эмулятор. Я должен был удалить .exe в эмуляторе, чтобы принудительно установить новое развертывание. Тогда это сработало.

Ответ 26

В Windows 7, Visual Studio Express 2010, если вы активировали опцию Использовать режим совместимости для Windows XP SP3, эта ошибка может возникнуть.

Я снял флажок, и он снова работал отлично. Щелкните правой кнопкой мыши ярлык на VS или исполняемый файл, выберите свойства, а затем совместимость.

Ответ 27

Сначала я попытался из командной строки;

удаление временных файлов из командной строки работало.

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Временные файлы ASP.NET > rd/s root

Когда я отключить параметр "Включить только мой код" в меню "Сервис" → "Параметры" → "Отладка" → "Общие"

Проблема решена для меня. Это приложение WCF, пыталось отладить страницу ashx. http://blogs.msdn.com/b/zainnab/archive/2010/10/25/understanding-just-my-code.aspx

Ответ 28

Я испытал это в 32-битной версии на vs2017.

Точно, ни один из решений не работал у меня. Я перезапустил, я очистил файлы IDE, чистое построенное решение, вытащил из git repo и перестроил решение безрезультатно.

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

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

Это была боль, я надеюсь, что она встанет в списке ответов, чтобы все могли видеть.

Изменить: во время сборки не было ошибок, несмотря на то, что в настройках IDE включена опция "Приглашение на сборку ошибок".

Ответ 29

Убедитесь, что вы не находитесь в режиме Release при попытке отладки.

Ответ 30

Если ваш отладочный процесс содержит несколько доменов приложений, и сборка загружается в оба, и одна из них загружает старую копию (обычно что-то динамически загруженную как плагин), точка останова может казаться сплошной, но поток, который должен попасть в точку останова находится в appdomain со старой сборкой и никогда не попадает. Вы можете увидеть, какие сборки загружены и их путь в окне модуля.