Отладчик Visual Studio пропускает контрольные точки

Моя Visual Studio 2008 IDE ведет себя очень странно, отлаживая unit test: у меня есть точка останова, и когда я ударил ее, а затем попытаюсь выполнить шаг с F10, завершение теста. Если я устанавливаю точки останова в каждой строке внутри тестируемого метода, я попаду в случайную, а не следующую в следующей строке. Я очистил и восстановил решение после чистой перезагрузки системы. Поведение сохраняется. Кто-нибудь еще испытал это и пришел к выводу.

В этом тесте использовался только основной поток выполнения (никаких дополнительных потоков не создается)

Ответ 1

Выпущено сообщение о выпуске post2008 SP1, которое решает ряд проблем отладки. Здесь находится статья KB здесь находится исправление для загрузки .

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

Ответ 2

Такое поведение происходит, если вы отлаживаете сборку релиза (поскольку линии оптимизированы).

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

Ответ 3

У меня были похожие проблемы на VS 2003. Оказалось, что я использовал неправильные символы, поэтому они не могли быть привязаны к правильному источнику.

Убедитесь в следующем:

Что вы используете сборку Debug (или отключена любая оптимизация)
Это построение выходного пути в порядке (что "Project Properties\Linker\Output File" соответствует exe, который вы отлаживаете)
Чтобы вы не размещали точки останова при объявлениях переменных: т.е. если вы поместите точку останова на "int some_variable;", вы никогда не ударяете ее, но вместо этого вы попадете на первое место после нее, где вы определяете\инициализируете что-то или вызываете некоторые методы.
Вы не можете входить в F10 (выполняет следующий оператор), но с F11 (выполняет следующий оператор и выполняет выполнение в вызовы методов)
Удостоверьтесь, что у вас нет фильтров на контрольных точках (т.е. количество или состояние попадания)

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

Ответ 4

Это также происходит, когда у вас есть несколько потоков.

Ответ 5

Даже в сборке Debug оптимизация компилятора может объяснить это поведение. В свойствах проекта "Build" убедитесь, что флажок "оптимизировать код" отключен. Я видел, что это включено по умолчанию после обновления некоторых проектов из .Net 1.1.

Ответ 6

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

Я столкнулся с этой проблемой на клиентском сайте справки службы. Сгенерированные классы являются частичными классами с

    [System.Diagnostics.DebuggerStepThroughAttribute()]

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

Я удалил этот атрибут из сгенерированного файла Reference.cs, и отладчик работал так, как я ожидал.

Конечно, это не постоянное решение, потому что если файл Reference.cs восстанавливается, атрибут возвращается.

Ответ 7

Это может быть так же просто, как в случае рамки тестирования, не загружая ту же сборку, над которой вы сейчас работаете. У меня это случалось в редких случаях в NUnit, который работает с копией вашей сборки под тестом; Иногда он перестал копировать самую последнюю версию. Ваши контрольные точки украшены индикатором "символы не были загружены"?

Ответ 8

Перейдите в Project- > Properties и снимите флажок "Оптимизировать код"

Это тот случай, если вы видите код, например DataSet ds = new DataSet(); попадает в отладчик, но код вроде строки Test = "Test"; пропускается.

Ответ 9

Может быть, слишком поздно отвечать, у меня есть такая же проблема в VS2012, чтобы исправить это, пожалуйста, проверьте, проверено ли меню Test > TestSettings > "LocalTestRun.TestRunConfig", если он установлен, снимите флажок и он перестанет пропускать код линий. Могут быть одинаковыми для Vs2008.

Ответ 10

Я столкнулся с этим в Visual Studio Community 2013. Поведение выглядит по дизайну. При выполнении тестов выполнение не останавливается на контрольных точках. Если вы хотите, чтобы выполнение остановилось на контрольных точках, выберите TEST → Debug, а не TEST → Run.

Ответ 11

Мои модульные тесты тестировались под x86. Сменили их на x64.

Меню

Test → Test Settings → Default Processor Architecture → x64.

Ответ 12

F10 - шаг Сверху, F5 продолжает следующую точку останова, F11 - шаг вперед, который выполняет следующую строку кода, а затем ждет. Это то, что вы, вероятно, ищете.

Ответ 13

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