Файл исходного кода отличается от того который использовался при построении модуля

Обновлено: 04.07.2024

При отладке в Visual Studio иногда я добавляю точку останова, но это пустое, а VS говорит: "В настоящий момент точка останова не будет удалена. Исходный код отличается от исходной версии". Очевидно, это мешает мне отлаживать.

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

        Ответ 5

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

        Ответ 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

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

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

        Ответ 12

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

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

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

                  Ответ 13

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

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

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

                  Ответ 14

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

                  Ответ 15

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

                  Ответ 16

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

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

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

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

                  Ответ 17

                  Решение состоит в том, чтобы включить свойство конфигурации среды выполнения 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

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

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

                  Ответ 28

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

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

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

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

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

                  Ответ 29

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

                  Ответ 30

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

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

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

                  Из-за этого я не могу протестировать какой-либо код, который написал сегодня.

                  • Как исходный код может отличаться от двоичного, если я только что его выполнил?
                  • Есть ли способ придать смысл визуальной студии, или я просто чего-то упускаю?
                  Извините, если это было многовато. Краткая версия: я компилирую свою программу, затем пытаюсь отладить ее, и Visual Studio сообщает мне, что мой исходный файл (который я только что скомпилировал) отличается от модуля, который я только что построил. Я просто хочу знать, почему он так думает

                  У меня возникла эта проблема при запуске консольного приложения, в котором источник, который отличался, был источником с точкой входа (static void Main). Удаление каталогов bin и obj и выполнение полной перестройки, казалось, исправили это, но каждый раз, когда я вносил изменение в код, он снова становился устаревшим.

                  Причина, по которой я это нашел:

                  1. Я проверил «Создавать только запускаемые проекты и зависимости при запуске» (Инструменты -> Параметры -> Проекты и решения -> Сборка и запуск)
                  2. В Configuration Manager в моем стартовом проекте не отмечена отметка "Сборка"

                  (Для №2 -> доступно через панель инструментов в раскрывающемся списке «Отладка / Выпуск».)

                  +1 за подсказку менеджера конфигурации. Я пытался разобраться с этим в течение часа, и все. У меня было несколько веток решения в TFS. Удаление каталогов bin и obj во всех проверенных ветках, похоже, прояснило ситуацию. в моем случае я был изменен solution platforms с Any CPU на Mixed Platform по ошибке . Я снова меняю его на, Any CPU и он снова работает. Спасибо, Решение> Свойства> Свойства конфигурации> Конфигурация, мое консольное приложение (которое запускает тесты для веб-приложения в том же sln) не было отмечено.

                  У меня была такая же проблема, все мои проекты были в одном решении, поэтому они использовали ссылки Project to Project, так что, если один изменил, другие должны были быть обновлены. Однако это было не так, я попытался собрать, перестроить, закрыть VS2010, вытащил новую копию из нашего источника. Ничего из этого не сработало, в конце концов я попробовал щелкнуть правой кнопкой мыши по проекту и перестроить каждый проект индивидуально. Это обновило файлы .dlls и .pdb, чтобы я мог выполнять отладку.

                  Проблема здесь в том, что ваши файлы dll и / или pdb не синхронизированы.

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

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

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

                  Я попытался удалить папки bin и obj из обоих решений и перестроить библиотеки DLL, а затем удалить и повторно добавить ссылку на dll в рамках первого проекта. Я не понимаю, почему он сказал бы мне, что исходный файл отличается от того, когда модуль был построен, когда я только что построил его и добавил ссылку.

                  Я думаю, что есть что-то простое, что я упускаю из виду, но я не знаю, что еще попробовать. Кто-нибудь еще исправлял подобную ситуацию раньше?

                  Edit: я только что попытался прикрепить исходный код из проекта, который на самом деле строит DLL, который я использую, и даже это не соответствует тому, где останавливается отладчик в моем коде. Кажется, я не могу найти способ найти местоположение DLL, которое используется отладчиком, но это определенно не тот, который я создаю.

                  Edit 2: мне удалось выяснить, что в "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files" была копия старого DLL, которую я удалил, но каждый раз, когда я запускал приложение, оно воссоздавало эту папку и файловую структуру точно так же, как это было раньше. Поэтому я сделал batch file, который запускаю каждый раз, когда компилирую свой проект, который тем временем копирует новый DLL в папку DNN bin.

                  2 ответа

                  Я хочу построить mod_wsgi против Python, который я построил сам из исходного кода в Ubuntu. (Вы можете видеть конкретно, как я его построил, как бы я сам построил python из исходного кода на Ubuntu? ) Я попытался запустить это из каталога mod_wsgi-3.3: $ sudo ./configure.

                  У нас была ситуация, когда у нас возникли проблемы с DLL, который был построен в нашем офисе, расположенном в Центральном часовом поясе, а затем развернут на сервере, расположенном на западном побережье (Тихоокеанский часовой пояс). У нас были бы проблемы с UTCDate out of range при попытке.

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

                  На данный момент у меня нет доступа к VS, но, если я правильно помню, когда вы нажимаете кнопку Выполнить в vs, окно вывода содержит путь ко всем загруженным библиотекам DLL. Проверьте там, действительно ли вы загружаете правильный модуль.

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

                  Правка: кроме того, не забудьте скопировать файл pdb! Поскольку вы ссылаетесь на dll, очень вероятно, что файл pdb для этого dll в папке bin не синхронизирован с только что созданной версией.

                  Кажется, я понял, почему IIS и VS использовали старую версию DLL. Это было потому, что у меня все еще была старая версия в папке DotNetNuke bin. Как только я фактически скопировал новый DLL из сборки проектов в корзину DNN, я смог пройти через код нормально. По какой-то причине мне никогда не приходило в голову на самом деле проверить там.

                  Похожие вопросы:

                  В настоящее время у меня есть одно решение, которое ссылается на десять файлов .dll. Эти файлы .dll, в свою очередь, ссылаются на общий файл .dll. Сегодня я начал получать ошибку во время отладки.

                  Это сводит меня с ума. У меня есть довольно большой проект, который я пытаюсь изменить. Ранее я заметил , что когда я набирал DbCommand , visual studio не делал на нем никакой подсветки синтаксиса.

                  Я хочу построить mod_wsgi против Python, который я построил сам из исходного кода в Ubuntu. (Вы можете видеть конкретно, как я его построил, как бы я сам построил python из исходного кода на Ubuntu.

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

                  Я декомпилировал файл .jar с помощью jd-gui и проверил коды, я обнаружил, что он отличается от исходного файла .java . оригинальный код if ( total != 0 ) < result[ i ] = bdResult.multiply( bdItem.

                  Я пытаюсь протестировать простой код Флинка, как показано ниже. Последовательность исходного набора данных равна 1,2,3,4 . После чтения файла последовательность потока равна `1,4,2,3'. Более того.

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

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

                  Я не могу проверить какой-либо из кода, который я написал сегодня из-за этого.

                  • Как источник может отличаться от двоичного, когда я просто выполнял Это?
                  • Есть ли способ сбить какой-то смысл в визуальную студию или Я что-то пропустил?

                  ОТВЕТЫ

                  Ответ 1

                  У меня возникла проблема с консольным приложением, где источник, который был другим, был источником, который имел точку входа (static void Main). Удаление каталогов bin и obj и полная перестройка, похоже, исправили это, но каждый раз, когда я делал изменение кода, он снова устарел.

                  Я нашел для этого следующее:

                  Ответ 2

                  У меня была такая же проблема, мои проекты были в одном решении, поэтому они использовали ссылки Project to Project, так как одна из них изменилась, остальные должны были быть обновлены. Однако это было не так, я попытался построить, перестроить, закрыть VS2010, вытащил новую копию из нашего источника управления. Ничего из этого не получилось, что я, наконец, пытался попробовать, это щелкнуть правой кнопкой мыши по проекту и перестроить каждый проект по отдельности. Это обновило файлы .dlls и .pdb, чтобы я мог отлаживать.

                  Проблема здесь в том, что ваши dll и ваши файлы pdb не синхронизированы.

                  Ответ 3

                  Выполните следующие действия.

                  • Просто удалите каталог bin из проекта, в котором создается DLL.
                  • Восстановите проект.
                  • Удалить ссылку из проекта, ссылающегося на DLL.
                  • Включить снова ссылку.
                  • Наслаждайтесь.

                  Ответ 4

                  Некоторые вещи для вас, чтобы проверить:

                  Вы дважды проверили ссылки на проекты?

                  У вас есть запущенный веб-сервер Visual Studio, который еще работает? Проверьте системный трей и найдите страницу со значком шестеренки (у вас может быть несколько):

                  Щелкните правой кнопкой мыши и закройте/выйдите из него. Вы можете иметь более одного. Можете ли вы отладить свои изменения сейчас?

                  Вы используете отладочную версию, но создали только версию выпуска (или наоборот)?

                  Ответ 5

                  В дополнение к этим ответам у меня возникла та же проблема при замене новых библиотек DLL на старые из-за неправильного пути. Если вы все еще получаете эту ошибку, вы можете не указывать неправильный путь для DLL. Перейдите в диспетчер IIS и щелкните веб-сайт, который использует ваши библиотеки DLL. В правом окне щелкните "Дополнительные параметры" и перейдите к пути к папке "Физический путь" в проводнике файлов и убедитесь, что вы используете эту папку для замены своих библиотек DLL.

                  Ответ 6

                  С помощью веб-служб проблема может быть вызвана использованием команды Visual Studio "Просмотр в браузере". Это помещает файлы DLL службы и PDB в папки bin и obj. При входе в веб-службу от клиента, как-то Visual Studio использует PDB в папке bin (или obj), но использует DLL в папке вывода вывода проекта. Есть несколько способов:

                  • Попробуйте удалить файлы DLL и PDB в корзине веб-сервиса и файлах obj.
                  • Попробуйте нажать "Просмотр в браузере" в Visual Studio.

                  Ответ 7

                  У меня была эта проблема.

                  Я пробовал все выше, но только это сработало:

                  • удалите файл .pdb для решения.
                  • удалить оскорбительные файлы .obj(для файла, который не синхронизирован)

                  Это фиксировало проблему для всех движений для меня.

                  Ответ 8

                  Вот как я исправил проблему в Visual Studio 2010:

                  1) Измените параметр "Конфигурации решений" с "Отладка" на "Отпустить"

                  2) Начать отладку

                  3) Остановить отладку и переключить опцию "Конфигурации решений" обратно в "Отладка"

                  Это сработало для меня. Шаг 3 является необязательным - он отлично работал, когда я изменил его на "Release", но я хотел его изменить.

                  Ответ 9

                  Я включил существующий проект из другого решения в новый файл решения.

                  Я не заметил, что когда существующий проект был перестроен, он помещал окончательный вывод в выходной каталог NEW. У меня был путь компоновщика, определенный для поиска в каталоге вывода OLD.

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

                  Ответ 10

                  У меня была эта проблема, и оказалось, что я запускаю консольное приложение в качестве приложения Windows. Исправлена ​​проблема переключения типа вывода на консоль.

                  Ответ 11

                  Ответ 12

                  Выгрузите проект с файлом, который вызывает ошибку.

                  Ответ 13

                  В Visual Studio 2017 удаление скрытой папки .vs в разрешенной для меня проблеме.

                  Ответ 14

                  Моя проблема заключалась в том, что у меня было два проекта в моем решении. Второй был тестовый проект, используемый для вызова первого. Я выбрал путь к ссылкам из папки выпуска папки bin.

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

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

                  Ответ 15

                  решение: - проблема в:- если ваши некоторые проекты в решении, обратитесь к некоторым другим проектам, то иногда dll некоторых проектов, не будет обновляться автоматически, всякий раз, когда вы строите решение, некоторые проекты будут иметь предыдущие DLL сборки, а не последние dll

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

                  Ответ 16

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

                  Мое решение:
                  1) Открыть Documents\IISExpress\config\applicationhost.config
                  2) Обновите virtualDirectory node с помощью каталога в новую копию и сохраните.

                  Ответ 17

                  Моя проблема заключалась в том, что у меня был веб-сервис в проекте, и я изменил путь сборки.

                  Восстановление пути сборки по умолчанию разрешило мою проблему.

                  Ответ 18

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

                  В итоге я открыл IIS и переработал пул приложений для своего веб-приложения. У меня есть версия IIS 8.5.9600, я щелкнул правой кнопкой мыши мое веб-приложение, а затем: Deploy > Recycle > Recycle pool pool > OK.

                  Кажется, что он исправил это, точки останова теперь попадают, как ожидалось. Я думаю, что делать это вместе с удалением папок bin и obj помогло мне в этом.

                  Ответ 19

                  Я знаю, что это старый вопрос, но у меня была такая же проблема, и я хотел опубликовать здесь, если это поможет кому-то другому. У меня появился новый компьютер, и ИТ-отдел объединил мой старый компьютер с новым. Когда я настраивал TFS, я сопоставил другой локальный путь, чем тот, который я использовал ранее, на дополнительный внутренний диск. Старый путь все еще существовал из объединенных данных на моем жестком диске, поэтому я все еще мог создавать и запускать. Мои пути IIS также указывали на старый каталог. Как только я обновил IIS до правильного пути, я смог отлаживать все отлично. Я также удалил старый каталог для хорошей меры.

                  Ответ 20

                  Я также испытал это. Я просто открываю папку obj в проекте, а затем открываю папку отладки, удаляю файл .pdb и все это.

                  Ответ 21

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

                  Я отлаживал метод из .dll другого одного из моих проектов, где Visual Studio довольно хорошо загрузил источник, потому что DLL был построен на той же машине, и он знал путь к источнику. Очевидно, что изменение такого файла ничего не сделает, если вы не восстановите ссылочный проект.

                  Ответ 22

                  • Удалить все точки останова.
                  • Перестроить.
                  • Готово

                  Ответ 23

                  В Visual Studio 2015 с использованием С++ для меня проблема the source file is different from when the module was built заключалась в

                  Ответ 24

                  Отладка- > запуск без отладки.

                  Этот вариант работал у меня. Надеюсь, это поможет!

                  Ответ 25

                  Проверьте правильность местоположения, на которое вы указали, используя mex() в Matlab (содержит файлы lib и obj, которые были изменены до последней даты, когда вы скомпилировали библиотеку в Visual studio).

                  Если это не так:

                  Убедитесь, что вы компилируете Visual studio в режиме, который сохраняет файлы .lib:

                  свойства → свойства конфигурации → общие сведения → тип конфигурации → статическая библиотека

                  Свойства → Свойства конфигурации → Общие → Целевое расширение =.lib (вместо exe)

                  Убедитесь, что выходные и промежуточные каталоги соответствуют каталогу Matlab в

                  1. свойства → свойства конфигурации → общие → выходной каталог
                  2. свойства → Свойства конфигурации → Общие → Промежуточный каталог

                  Ответ 26

                  В моем случае ответ @Eliott не работает. Для решения этой проблемы мне пришлось исключить/включить из проекта мой дефектный файл, а также очистить и перестроить решение.

                  После этих действий мой файл с моими последними изменениями и отладчиком восстанавливаются.

                  Я надеюсь, что это поможет.

                  Ответ 27

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

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

                  Ответ 28

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

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

                  В следующих двух разделах описаны наиболее часто возникающие предупреждения и способы их устранения.

                  "Нет загруженных символов для этого документа"

                  Перейдите в окно Модули (Отладка > Окна > Модули) и проверьте, загружен ли модуль.

                  Если модуль загружен, проверьте, загружены ли символы, в столбце Состояние символов.

                  • Если символы не загружены, проверьте состояние символов для диагностики проблемы. В контекстном меню модуля в окне Модули щелкните Сведения о загрузке символов. , чтобы узнать, откуда отладчик пытался загрузить символы. Дополнительные сведения о загрузке символов см. в статье Указание файлов символов (.pdb) и исходных файлов.
                  • Если символы загружены, PDB-файл не содержит сведений об исходных файлах. Возможно несколько причин.
                    • Если исходные файлы были добавлены недавно, убедитесь в том, что загружается последняя версия модуля.
                    • Можно создать очищенные PDB-файлы с помощью параметра компоновщика /PDBSTRIPPED. Очищенные PDB-файлы не содержат сведений об исходных файлах. Убедитесь в том, что вы работаете с полным, а не очищенным PDB-файлом.
                    • PDB-файл частично поврежден. Удалите файл и выполните чистую сборку модуля, чтобы попытаться устранить проблему.

                    Если модуль не загружен, проверьте следующее, чтобы найти причину:

                    "… текущий исходный код отличается от версии, построенной в. "

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

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

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

                    • Чтобы изменить отдельную точку останова, наведите указатель мыши на значок точки останова в редакторе и щелкните значок параметров (в виде шестеренки). В редактор добавится окно просмотра. В верхней части окна просмотра есть гиперссылка, указывающая на расположение точки останова. Щелкните гиперссылку, чтобы разрешить изменение расположения точки останова, и установите флажок Разрешить наличие отличий в исходном коде от первоначальной версии.
                    • Чтобы изменить этот параметр для всех точек останова, выберите Отладка > Параметры и настройки. На странице Отладка / Общие снимите флажок Требовать точного соответствия исходной версии файлов . Не забудьте снова включить этот параметр после завершения отладки.

                    Точка останова была установлена успешно (без предупреждения), но не сработала

                    В этом разделе содержатся сведения об устранении неполадок в ситуации, когда отладчик не выводит предупреждений — точка останова представлена закрашенным красным кружком во время отладки, но не срабатывает.

                    Вот несколько моментов, которые следует проверить.

                    После удаления точки останова она по-прежнему применяется при запуске отладки

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

                    Читайте также:

                      
                    • Залипает стик на psp
                      
                    • Как сделать сетку в 3д макс
                      
                    • Как отключить уведомления инстаграм на компьютере
                      
                    • Как называется порт интернета в компьютере
                      
                    • Как варить материнская плата