Инструменты отладки: System.Diagnostics, Output window, DebuggerDisplay, Edit and continue, Immediate Window и т.д

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

Пространство имен System.Diagnostics 

Если говорить о инструментарии, который уже имеется в составе .NET Framework, тогда речь пойдут о классах лежащих в пространстве имен System.Diagnostics.* . Из всего многообразия классов я выделю только те, которые помогут нам в разработке.

Класс взаимодействия с отладчиком (Debugger).

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

Метод Debugger.Launch() 

Launch работает так по правилам:

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

Простенький пример консольного приложения:

using System.Diagnostics;
 
namespace DebugFeatures
{
    internal class Program
    {
        private static void Main(string[] args)
        {
            Debugger.Launch();
        }
    }
}

Запустив по F5 в студии вы ничего не заметите, но запусти в проводнике увидите диалог:

В котором можете выбрать либо уже запущенную студию (у меня это 1-я строка), либо использовать новый экземпляр студии по вашему выбору.

Внимание! Если "New instance Microsoft ....", тогда весь код проекта будет не доступен. Поэтому желательно выбирать студию с отрытым вашим проектом.

Теперь по поводу жизненных ситуаций, когда этот метод пригодится:

• При отладке двух процессов, когда ваше приложение запускает второе приложение, которое быстро "что то делает" и закрывается. При этом вы не успеваете сделать Debug -> Attach to process.
• Допустим вы являетесь разработчиком какого то расширения или add-on для какой то системы. При запуске система подгружаете ваш модуль в память и передает ему управление. Встает вопрос, как же теперь отлаживать ситуацию в момент запуска модуля? В этом случае добавляем в код метода Debugger.Launch() и в момент запуска получаем возможность отладить процесс запуска.
  P. S. Если вы пользуетесь Thread.Sleep(15000) + Attach to process, то мои вам соболезнования :)

Важно! Стоит помнить что даже в релизной сборке будет отображаться окно с отладчиками, поэтому не забывайте удалять Debugger.Launch(), когда надобность в нем отпадает.
 

Метод Debugger.Break()

Break работает по правилам:

• Если отладчик подключен, то происходит остановка при вызове методе, сравнимая остановке на breakpoint.
• Если же отладчик не подключен и вызывается метод Break(), тогда будет показано окно с выбором отладчика, но при этом закрыв его приложение продолжит работу.

Пример кода:

using System.Diagnostics;
 
namespace DebugFeatures
{
    internal class Program
    {
        private static void Main(string[] args)
        {
            int a = 1;
            while (a < 10 * 1000 * 1000)
            {
                a ++;
                if (a == 9*999* 999)
                {
                    Debugger.Break();
                }
            }
        }
    }
} 

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

 Output window и класс Debug.

Мне кажется, что люди не дооценивают окно Output внутри Visual Studio убирая его с рабочего пространства, а ведь это просто идеальная консоль для вывода событий происходящих в приложении и просто спасительный круг, если вы отлаживаете сложное многопоточное приложение. Либо пытаясь распутать какие то ситуации, где требуется анализ параметров и локальных переменных, что бы понять причину неисправности. Сейчас я постараюсь продемонстрировать как использовать Output, но при этом не загромождать им место.

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

• Окно Output не присутствует на видимом рабочем пространстве. А находится где то снизу на вкладках, при этом программист может иногда поглядывать туда.
• Окно Output всегда видно, но имеет настолько малый размер, что в нем ничего не понятно. При сборке что то мелькает, а на вопрос "Зачем тебе оно если ничего не понятно?" получал ответ "Что бы знать, что студия не подвисла и было на что поглядеть". 
• Последний вариант, программист активно пользуется им и читает, что пишется в окне. Но при этом в окне два scroll умещается 4-6 строчек, а при работе приложение внутри мелькает текст и бедняга программист пытается найти нужное место.

Если вы из пункта 3 тогда хотел бы предложить мой способ размещения окна, которым я пользуюсь и перенастраиваю везде уже так в течении 5 лет. На всё про всё уходит 5-10 минут, но бывают и такие которые годами будут пользоваться неудобным интерфейсом или способом, при этом зная, что правится проблема в считанные минуты, но человеку "Лениво разбираться" :)