Visual Studio отладчик советы и рекомендации для.NET
Я годами работал с отладчиком VS, но время от времени я сталкиваюсь с особенностями, которых я никогда раньше не замечал, и думаю: "Черт! Как я мог пропустить это? Это так полезно!"
[Отказ от ответственности: эти советы работают в VS 2005 над проектом C#, никаких гарантий для более старых версий VS или других языков]
Отслеживать экземпляры объекта
Работаете с несколькими экземплярами данного класса? Как вы можете отличить их? В дни программирования перед сборкой мусора было легко отслеживать ссылки - достаточно взглянуть на адрес памяти. С.NET вы не можете этого сделать - объекты могут перемещаться. К счастью, вид часов позволяет вам щелкнуть правой кнопкой мыши на часах и выбрать "Сделать идентификатор объекта".
Это добавляет {1#}, {2#} и т. Д. После значения экземпляра, фактически давая экземпляру уникальную метку. Это выглядит так:
Метка сохраняется в течение всего времени существования этого объекта.
Значимые значения для наблюдаемых переменных
По умолчанию значение наблюдаемой переменной - это ее тип. Если вы хотите увидеть его поля, вы должны расширить его, и это может занять много времени (или даже тайм-аут!), Если есть много полей или они делают что-то сложное.
Однако некоторые предопределенные типы показывают более значимую информацию:
- строки показывают их фактическое содержание
- списки и словари показывают их количество элементов и т. д.
http://img205.imageshack.us/img205/4808/37220487md1.jpg
Разве не было бы хорошо иметь это для моих собственных типов?
Хм...
... некоторое время, проведенное с.NET Reflector, показывает, насколько легко это можно сделать с помощью DebuggerDisplay атрибут моего пользовательского типа:
[System.Diagnostics.DebuggerDisplay("Employee: '{Name}'")]
public class Employee {
public string Name { get { ... } }
...
}
... повторно и...
та да! http://img60.imageshack.us/img60/926/79816018ha1.jpg
Здесь есть намного больше информации по этому вопросу: MSDN
Перерыв на все исключения
... даже те, которые обрабатываются в коде! Я знаю, что я такой неопытный, что не знаю об этом с тех пор, как я родился, но все же так и есть - возможно, это когда-нибудь кому-нибудь поможет:
Вы можете заставить отлаживаемый процесс переходить в режим отладки каждый раз, когда выдается исключение. Когда-нибудь часами ходили на охоту за ошибками, чтобы наткнуться на такой фрагмент кода?
try {
runStrangeContraption();
} catch(Exception ex) {
/* TODO: Will handle this error later */
}
Ловить все исключения действительно удобно в этих случаях. Это можно включить в меню "Отладка"> "Исключения..." (Ctrl-Alt-E). Установите флажки в столбце "Брошенные" для каждого необходимого исключения.
Это были несколько удачных моментов для меня. Хотите поделиться своим?
14 ответов
Два трюка в коде:
Мне действительно нравится атрибут System.Diagnostics.DebuggerStepThrough; Вы можете прикрепить его к классу, методу или свойству, чтобы VS не вводил код по умолчанию при отладке. Я предпочитаю его атрибуту DebuggerHidden, так как он все еще позволит вам ставить точки останова в игнорируемом коде, если вам действительно нужно его отладить.
Еще один (иногда) полезный вызов - System.Diagnostics.Debugger.Launch (); когда выполнение достигнет его, вы увидите диалоговое окно "Выбор отладчика", и отладчик запустится. Немного грубый, но полезный, особенно неприятный для присоединения к процессам, например, процесс, который порождается другим и немедленно выполняет ваш код.
try {
// do something big
}
catch {
// breakpoint set here:
throw CantHappenException("something horrible happened that should never happen.");
}
Как вы видите исключение, которое было первоначально выброшено? В окне просмотра введите $ исключение
Вот еще одна изящная уловка, которую я выучил:
System.Diagnostics.Debugger.Break()
программно вызывает сбой отладчика при следующей инструкции. Хорошая часть в том, что это также работает для программы, скомпилированной в режиме Release, без отладочной информации.
Я всегда устанавливаю свойство "Имя" в новых создаваемых мной потоках. Таким образом, когда я отлаживаю, мне легче идентифицировать разные потоки.
Конечно, проверьте совет дня VS:
Некоторые из меня
- Снимите флажок "Включить только мой код" в Сервис-> Параметры-> Отладка.
- Условные контрольные точки - они спасают мою жизнь почти каждый день
- Используйте исходный код.NET Framework, если все становится плохо
Я нашел окно "Модули" полезным много раз. Он сообщает, загрузил ли отладчик требуемую dll и какая версия dll загружена. Это также позволяет вам вручную загружать или выгружать DLL.
Инструменты -> Присоединить к процессу - легко забыть, но с его помощью я могу отлаживать скрипт на веб-страницах, управляемый код, загруженный в другой процесс (например, модель надстройки), или даже неуправляемый код. Будьте внимательны, позволяя ему автоматически выбирать тип отладки, который вас интересует.
Точки трассы (и другие функции точки останова... щелкните правой кнопкой мыши на точке останова и получайте удовольствие)! - http://blogs.msdn.com/saraford/archive/2008/06/13/did-you-know-you-can-use-tracepoints-to-log-printf-or-console-writeline-info-without-editing-your-code-237.aspx
Непосредственное окно потрясающее.
Удаленная отладка очень полезна, если вы развертываете приложения (и можете добраться до машины, где проблема может быть воспроизведена).
Есть тонны больше. Попробуйте войти в WinDbg и SoS!
Условные разрывы очень полезны, если у вас есть код, который многократно повторяется, но происходит сбой только при определенном наборе условий, таких как код в цикле, методы, вызываемые из цикла, или методы, вызываемые из нескольких потоков. Поместите оператор break в интересующую линию и установите его условия, соответствующие случаю ошибки. (Здесь приведен быстрый пример.)
Два от меня: один, который я надеюсь, что все используют повсюду:
Debug.Assert(<condition>, <message>)
второй DebuggerHidden:
<DebuggerHidden()> _
Public Sub ReadDocumentProperty(ByVal propertyName As String, ByRef PropVal As Integer, ByVal DefaultVal As Integer)
Try
Dim prop As Office.DocumentProperty
prop = CustomProps.Item(propertyName)
PropVal = CType(prop.Value, Integer)
Catch
PropVal = DefaultVal
End Try
End Sub
Даже если у вас есть Отладка, Исключения, Разрыв на выброшенные исключения, исключения здесь не будут перехвачены.
Как насчет настройки среды IDE для разбиения на исключения, когда они возникают, даже если у нас не установлена ни одна точка отладки.
Отладка -> Исключения -> Исключения среды выполнения языка Commmon -> Брошенный
Это делает поиск скрытых проблем обработки исключений легким. На самом деле, это своего рода настройка, которую каждый разработчик должен установить во время разработки, чтобы избежать каких-либо необработанных или даже обработанных исключений, которые встречаются ниже.
Создайте макрос для присоединения к процессу и назначьте неиспользуемое сочетание клавиш. Гораздо быстрее, чем идти: отладка -> присоединиться к процессу -> поиск процесса в списке процессов ->...
В неуправляемом коде вы можете установить "точки останова данных". Они используют регистры отладки ЦПУ для выдачи INT3, и отладчик останавливается на этой инструкции без перегрузок во время выполнения (в более старой версии отладчик прошел программу, проверяя память..... медленно!)
Это полезно, если у вас есть некоторая порча по неизвестному адресу (стек / куча могут быть повреждены).
Также AutoExp.dat в ide\packages\debugger может быть настроен для отображения ваших структур данных.
указатель, mb показывает шестнадцатеричный дамп в окне просмотра http://msdn.microsoft.com/en-us/magazine/dd252945.aspx
Yum!