Точка останова не подключается при отладке в VS.Net 2005

Question

В последнее время сталкиваюсь с этой проблемой ... При отладке приложения в VS.Net 2005 точки останова не подключаются. Ошибка указывает, что скомпилированный код не совпадает с работающей версией, и поэтому существует несоответствие, которое приводит к отключению точки останова.

Чистое решение всех бинарных файлов и повторная компиляция не помогают. Не только на одной коробке или человеке.

Добавлено примечание: Это решение находится в TFS для контроля версий. Если я удаляю свой локальный репозиторий TFS и получаю его из системы контроля версий с нуля, ИНОГДА проблема исчезнет. Я также попытался удалить и переустановить Visual Studio. Это также помогает ИНОГДА. Тот факт, что оба из них работают некоторое время, указывает на то, что проблема не вызвана напрямую.

Answer 1

Может быть, это предложение может помочь:

1. Во время отладки в Visual Studio нажмите Отладка> Windows> Модули. Среда IDE закрепит окно модулей, показывая все модули, которые были загружены для вашего проекта.
2. Найдите библиотеку DLL вашего проекта и проверьте ее состояние символа.
3. Если там написано "Символы загружены", значит, ты золотой. Если там написано что-то вроде «Не удается найти или открыть файл PDB», щелкните правой кнопкой мыши по вашему модулю, выберите «Загрузить символы» и найдите путь к вашей PDB.

Я обнаружил, что иногда необходимо:

1. остановка отладчика
2. закрыть IDE
3. закрыть приложение хостинга
4. Nuke папки obj и bin
5. перезапустить IDE
6. пересобрать проект
7. снова пройти через окно модулей
8. Как только вы перейдете к местоположению вашего файла PDB, статус символа должен измениться на Символы загружены, и теперь вы сможете устанавливать и перехватывать точку останова на вашей строке в коде.

Источник: Точка останова в настоящее время не будет достигнута. Для этого документа не было загружено никаких символов.

Answer 2

http://dpotter.net/Technical/2009/05/upgrading-to-ie8-breaks-debugging-with-visual-studio-2005/

Answer 3

У меня была похожая проблема в прошлом.

Это было решено закрытием Visual Studio и удалением временных сгенерированных ASP.NET файлов сборки для проекта в папке «C: \ WINDOWS \ Microsoft.NET \ Framework {version version} \ Temporary ASP.NET Files», повторное открытие проект.

Прочтите пост здесь и комментарии, чтобы решить его.

Answer 4

Вы создаете проект DLL, который используется внешним исполняемым файлом? Вы используете .NET или COM?

Если вы используете COM Interop с .NET, версии DLL могут иногда быть проблемой, когда исполняемый файл загружает DLL. Например, если ваша ежедневная сборка запускает увеличивающийся номер сборки, но ваша отладочная DLL имеет меньший номер сборки, исполняемый файл не будет загружать отладочную DLL. Чтобы это исправить, вам нужно отсканировать каталог HKEY_CLASSES_ROOT \ CLSID в вашем реестре на наличие GUID / CLSID вашего компонента .NET / COM. В InProc32 удалите записи с более высоким номером версии, чем в вашей отладочной DLL.

Опять же, вышеизложенное относится только к .NET + COM Interop DLL.

Answer 5

Конфигурация сборки установлена ​​в Release?

У вас есть ссылка на внешнюю DLL, в которой установлена ​​точка останова?

Answer 6

В Options -> Debugging вы можете снять галочку «требовать, чтобы исходные файлы точно соответствовали исходной версии», что может помочь.

Answer 7

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

Answer 8

Конечно, в коде нет атрибутов Debug, которые мешают отладке кода, например DebuggerHidden или DebuggerStepThrough, в любой точке приложения?

Answer 9

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

Это звучит как другая проблема, но, возможно, стоит убедиться, что оптимизация отключена в режиме отладки. [Проект / Свойства, вкладка Настройки сборки]

Answer 10

Есть ли у вас шаг после сборки, который каким-либо образом касается ваших двоичных файлов? Если это так, это может сбить с толку отладчик и привести к тому, что ваши символы не будут соответствовать вашему exe / dll из-за неправильного размера / метки времени.