Отладчик Visual Studio 2010 работает над методами и не останавливается на контрольных точках

Ответ 1

Я нашел решение проблемы, и это действительно просто:

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

Ответ 2

Вот несколько причин и обходных решений для того, почему Visual Studio избегает перехода к определенному методу.

• Только мой код включен. В определенных обстоятельствах параметр "Только мой код" не позволит вам перейти в метод/свойство. Чтобы избежать этого, вы можете отключить "Только мой код" на странице параметров отладчика (Инструменты → Параметры → Отладчик → Снимите флажок "Только мой код" )
• Символы не загружаются для целевого метода. Если целевой метод является частью другой DLL, возможно, что символы не загружаются для этой DLL, и, следовательно, Visual Studio не сможет войти в нее по умолчанию. Чтобы заставить символы загружаться, откройте представление модулей (Debugger → Windows → Modules), перейдите к DLL, содержащей этот метод, щелкните правой кнопкой мыши и загрузите символы.
• Метод явно помечен атрибутом отладчика, таким как DebuggerNonUserCode, который заставляет отладчик переходить на этот метод.
• Метод на самом деле является свойством или оператором, и у вас включен параметр "Перейдите по свойствам и операторам" (это значение по умолчанию). Это можно отключить через диалог параметров отладчика.

Ответ 3

В моем случае это были "Step Over Properties и Operators" в Tools → Options → Debugger. Просто нужно было снять этот флажок, и после этого все было в порядке, я мог бы вмешаться.

Ответ 4

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

Если точка останова выглядит нормально, но все же вы не можете войти в этот метод, попробуйте очистить кэш теневого копирования: http://weblogs.asp.net/mreynolds/archive/2003/08/11/23576.aspx

Еще одна вещь, которую стоит попробовать - убедиться, что вы действительно используете DLL, которую вы только что перестроили, добавив MessageBox.Show(или что-то подобное) к методу, с которым вы, похоже, не можете остановиться, и убедитесь, что вы получите поле.

Ответ 5

Другим источником путаницы являются методы итератора, которые используют оператор yield return, потому что они переписываются компилятором С# таким образом, что переход в них (F11) вид no-op ".

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

Ответ 6

WAG, но я бы сказал, что вы ссылались на другой проект в своем решении BROWSING на dll (project/bin/debug/mydll.dll), а не на добавление "Project Reference". Если в вашем решении есть несколько проектов, удалите ВСЕ ссылки на каждый проект. Затем в диалоговом окне "Добавить ссылку" перейдите на вкладку "Добавить ссылку на проект" и выберите проект, который вы хотите установить.

Ссылки на проекты всегда обновляются в новой сборке. Но если вы, скажем, перейдете к bin/release и добавьте ссылку на DLL в этом каталоге, когда вы переключаетесь в режим отладки и добавляете код и пытаетесь его отладить, старая версия dll загружается в appdomain и VS не сможет ударить по любым точкам останова (вы заметите, что точки останова - это пустые круги, а всплывающая подсказка что-то скажет о том, что код не загружается).

Ответ 7

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

• Убедитесь, что проект находится в режиме отладки (все проекты)
• В Windows перейдите в командную строку и обязательно запустите ее как администратор
• Перейдите к c:\windows\syswow64\ (или папке, где находится gacUtil.exe)
• Выполните следующую команду (замените путь ниже туда, где находится отладочная версия DLL.

gacutil /i "C:\Users\John\Documents\Visual Studio 2008\Projects\Project1\Project1\bin\Debug\MyAppDLL.dll"

Вы должны получить "Сборка успешно добавлена ​​в кэш"

Теперь запустите проект и вы сможете войти в DLL-код.

Ответ 8

Я только что нашел другую причину проблемы и исправить. Я создаю приложение Windows Forms с использованием С++ в Visual Studio 2010. Я использую библиотеку FreeType и некоторый код, который зависит от нее, и по разным причинам этот код должен быть скомпилирован с помощью "Нет поддержки общего времени выполнения языка" (Свойства → Свойства конфигурации → Общие). Я не смог получить точки останова, чтобы попасть в этот код без CLR.

Исправление состоит в том, что основное приложение должно быть скомпилировано с помощью "Common Language Runtime Support (/clr)", NOT 'Pure MSIL Common Language Runtime Support) (/clr: pure)'. Это сразу решило проблему. Теперь я могу отлаживать и удалять точки останова в коде, отличном от CLR, включая код FreeType C.

Ответ 9

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

Ответ 10

Попробуйте отключить опцию "Требовать, чтобы исходный файл был точно сопоставлен" в инструментах- > options- > debugging- > general.

Ответ 11

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

Ответ 12

Моя проблема была простой. У меня есть несколько проектов в решении, и мне просто нужно настроить проект, с которым я работаю, в качестве Set As Startup Project.