При отладке в Visual Studio иногда я добавляю точку останова, но это пустое, а VS говорит: "В настоящий момент точка останова не будет удалена. Исходный код отличается от исходной версии". Очевидно, это мешает мне отлаживать.
Что означает это сообщение? Какая оригинальная версия? Если я только что открыл решение и не внесло никаких изменений в код, как может быть "оригинальная версия"?
Как говорится, "исходный код отличается от исходной версии".
Щелкните правой кнопкой мыши папку проекта внутри проводника решений и выберите Clean. Создайте новую версию проекта, и точка останова будет работать снова!
Если вы отменили проект DLL в конфигурации сборки Debug, ваш новый код никогда не будет создан!
Перейдите к Build --> Configuration Manager ... (в VS2010) и проверьте, проверен ли проект с кодом, который вы пытаетесь отладить, для текущей конфигурации сборки.
Для меня это было во время работы над проектом WebSite. После очистки этих временных папок я получил правильные ошибки компилятора:
C:\Documents and Settings\%username%\AppData\Local\Temp\Temporary
ASP.NET FilesC:\windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET
FilesЯ, наконец, решил проблему, когда обнаружил, что файл класса, который я намеренно переместил во вложенную папку, каким-то образом появился в корневой папке. VS использовал тот, пока я редактировал другой.
Вы когда-нибудь делали это?
Вы хотите продолжить и запустить последнюю успешную сборку?
Если вы отметили поле и нажали "Да", вы получите последнюю успешную сборку, даже если ваш проект не компилируется. Это означает, что всякий раз, когда вы устанавливаете точку останова, вы получите эту ошибку.
Попробуйте изменить это значение:
Перейдите к
Снимите флажок Требовать, чтобы исходные файлы соответствовали исходной версии
Выберите Отладка в Конфигурация решений, а не Отпустить
Обратите внимание на окно "Выход" в VS. Он расскажет вам, какие сборки загружены и когда. Вы можете увидеть, что загружается более старая версия вашей сборки где-то в папке.
Например, если у вас есть несколько сборок, и вы в настоящее время пытаетесь взломать одну из сборочных сборок, CLR будет обрабатывать решение сборки, которое может загрузить другой файл сборки, чем тот, на который вы ссылались в проекте.
Закрытие Visual Studio и повторное открытие решения могут устранить проблему, то есть ошибку в самой IDE (я запускаю VS2010).
Если у вас несколько экземпляров Visual Studio, вам нужно только закрыть экземпляр, запускающий решение с проблемой.
Новый способ решения этой проблемы появился в Visual Studio 2017 с 15.3.1 по 15.3.5. Если вы используете EditorConfig, опция charset=utf8 вызывает эти симптомы. Команда VS воспроизвела это и говорит, что работает над этим.
Итак, одно из исправлений - закомментировать строку charset=utf8 в файле .editorconfig.
Изменение: это должно быть исправлено с VS 15.5.
Это часто случается также, если вы используете ссылки на файлы для двоичных файлов (вместо ссылок на проекты на код в вашем проекте), а скомпилированный двоичный файл, который вы ссылаетесь, выпадает из синхронизации с соответствующим исходным кодом на вашем компьютере. Это может произойти из-за того, что вы загрузили новую версию двоичного кода из исходного элемента управления без нового исходного кода, который был с ним, или у вас есть несколько версий двоичного файла на вашем компьютере и ссылаются на старую копию и т.д. Если это действительно проблема, это хорошая причина использовать ссылки на проекты, насколько это практически возможно.
Для меня ни один из пунктов не решил проблему. Я просто добавил новую строку кода внутри этой функции, что-то вроде:
int a=0;
добавив, что, я думаю, я вызвал Visual Studio, чтобы добавить эту функцию в исходную версию
Существует почти незаметная настройка, которая фиксировала эту проблему для меня. Если есть определенный исходный файл, в котором точка останова не попадает, он может быть указан в
По какой-то причине мне неизвестно, VS 2013 решил разместить там исходный файл, и впоследствии я больше не мог ударить точку останова в этом файле. Это может быть виновником "исходного кода отличается от исходной версии".
Проблема заключается в том, что ваша информация об отладке не синхронизируется с вашей сборкой. Решение прост:
Сделайте трюк!
(странно, перестройка, не отбрасывающая файлы .pdb, не всегда работает. Я вижу обновленную дату обновления, но все же где-то в цепочке (отладчик VS2013, IIS, кеш сборки) это изменение не обнаружено)
Это может произойти, когда системное время изменяется во время отладки или между сеансами отладки, будь то программно, вручную или внешней программой.
Вы можете получить это сообщение, когда используете активатор, а сборка, в которую вы установили точку останова, еще не загружена.
Точка останова будет устранена после того, как активатор загрузит сборку (при условии, что символы сборки и отладки обновлены). Хорошее место для просмотра - это окно модулей в меню отладки. Там вы должны искать сборку, к которой принадлежит ваш файл. Сначала проверьте, что сборка загружена. Затем, откуда он загружен? Затем загружается файл символов. Опять же, где загружен файл символов? Наконец, проверьте версии обоих.
Я тоже столкнулся с этим. Условия, которые вызвали мою проблему:
Я вызвал это, открыв предыдущую версию (VS попросил спросить, хочу ли я указать на этот экземпляр в отладке IIS, я ответил "Да" ), затем открыв текущую версию (снова отвечая на запрос IIS "Да" ), затем попытка отладки в предыдущей версии.
Чтобы решить проблему, я просто закрыл и повторно открыл предыдущую и предполагаемую версию, еще раз подтвердив ее как источник отладки.
Это происходит также при отладке проекта С++, который загружает модуль, который был реализован с помощью некоторого языка CRL (Managed С++, С# и т.д.). В этой ситуации сообщение об ошибке действительно вводит в заблуждение.
Решение состоит в том, чтобы включить свойство конфигурации среды выполнения Common CLR в проект запуска и перекомпилировать это.
Попробуйте отключить и повторно установить контрольную точку во время работы в режиме отладки, а не выполнять ее до запуска режима отладки.
Если у вас есть несколько проектов в вашем решении, убедитесь, что правильный проект установлен как StartUp Project. Чтобы настроить конкретный проект как проект запуска вашего решения, щелкните правой кнопкой мыши проект, выберите Set As StartUp Project.
После того, как я правильно установил проект StartUp, желаемый момент прерывания был достигнут потоком.
идти к:
Сервис> Параметры> Отладка> Общие> не отмечено "Требовать, чтобы исходные файлы точно соответствовали исходной версии"
Для меня решение было скрыто в Advanced Build Settings свойств проекта:
По неизвестной причине он был установлен в none: установка его на full заставила точки останова попасть.
Чтобы перейти в это диалоговое окно, откройте свойства проекта, затем перейдите к Build, затем нажмите кнопку Advanced... в нижней части страницы.
У меня была такая же проблема в нескольких проектах в проекте многоуровневой архитектуры, и проблема была в конфигурации, флажок сборки для выбранного проекта не был отмечен. поэтому проблема была решена для одного проекта.
Для одного другого слоя это создавало такую же проблему, даже если в настройках включена сборка. Я сделал все другие варианты, такие как возобновление очистки проекта, но ни один из них не помог. Наконец, я снял флажок сборки для этого конкретного проекта и очистил и пересобрать. Снова отметили флажок и сделали то же самое. тогда проблема была решена.
Надеюсь это поможет..
Что сработало для меня, так это изменить платформу решений от x86 до Any CPU. После перехода на Any, я установил адрес остановки, запустил веб-сайт, открыл страницу, нажал кнопку и остановился. Я закрыл сайт, сменил его на x86 и успешно выполнил ту же последовательность.
В моем случае я присоединился к запущенному процессу в VS 2012. При подключении вам предоставляется возможность отладки в различных режимах (native, script, silverlight, managed 2.0, managed 4.0 и т.д.). По умолчанию отладчик автоматически выбирает режим. Однако Automatic не всегда делает правильный выбор. Если ваш процесс содержит несколько типов кода, убедитесь, что отладчик использует правильный.
В моем случае я разрабатывал приложение Windows CE, которое протестировало против эмулятора. Проблема заключалась в том, что исполняемый файл не был размещен в эмуляторе, поэтому .pdb(в среде разработки) не синхронизировался с .exe(в эмуляторе), потому что новый .exe никогда не копировался в эмулятор. Я должен был удалить .exe в эмуляторе, чтобы принудительно установить новое развертывание. Тогда это сработало.
В Windows 7, Visual Studio Express 2010, если вы активировали опцию Использовать режим совместимости для Windows XP SP3, эта ошибка может возникнуть.
Я снял флажок, и он снова работал отлично. Щелкните правой кнопкой мыши ярлык на VS или исполняемый файл, выберите свойства, а затем совместимость.
Сначала я попытался из командной строки;
удаление временных файлов из командной строки работало.
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
Я испытал это в 32-битной версии на vs2017.
Точно, ни один из решений не работал у меня. Я перезапустил, я очистил файлы IDE, чистое построенное решение, вытащил из git repo и перестроил решение безрезультатно.
Я забирал 64-битную зависимость от nuget, и как только я использовал сборку, источники больше не встраивались в окончательный исполняемый файл, а вместо этого создавались источники кэширования IDE.
Я удалил конфигурацию nuget, удалил ссылочную сборку, загрузил исходный код, создал log4net вручную, подписал его, добавил в папку в моем проекте, добавил ссылку на него, и я смог снова отлаживать.
Это была боль, я надеюсь, что она встанет в списке ответов, чтобы все могли видеть.
Изменить: во время сборки не было ошибок, несмотря на то, что в настройках IDE включена опция "Приглашение на сборку ошибок".
Убедитесь, что вы не находитесь в режиме Release при попытке отладки.
Если ваш отладочный процесс содержит несколько доменов приложений, и сборка загружается в оба, и одна из них загружает старую копию (обычно что-то динамически загруженную как плагин), точка останова может казаться сплошной, но поток, который должен попасть в точку останова находится в appdomain со старой сборкой и никогда не попадает. Вы можете увидеть, какие сборки загружены и их путь в окне модуля.