Как посмотреть логи visual studio

Обновлено: 06.07.2024

Для отладки определенной веб-страницы в Visual Studio выберите эту веб-страницу в окне Solution Explorer и щелкните на кнопке Start Debugging (Начать отладку) в панели инструментов. (Если вы в данный момент редактируете веб-страницу, которую собираетесь тестировать, то выбирать ее нет необходимости — просто щелкните на кнопке Start Debugging для ее запуска.)

Дальнейшие события зависят от расположения вашего проекта. Если ваш проект хранится на удаленном веб-сервере или локальном виртуальном каталоге IIS, Visual Studio просто запускает браузер по умолчанию и направляет на соответствующий URL.

Если вы использовали приложение файловой системы, Visual Studio запускает свой встроенный веб-сервер на динамически выбранном порту (который предотвращает конфликт с IIS, если он установлен). Затем Visual Studio запускает браузер по умолчанию и передает ему URL, указывающий на локальный веб-сервер. В каждом случае реальная работа — компиляция страницы и создание объектов страницы — передается рабочему процессу ASP NET.

Тестовый сервер запускается только на время работы Visual Studio и принимает запросы исключительно от данного компьютера. После запуска встроенного веб-сервера Visual Studio добавляет в область значков панели задач представляющий его значок. Чтобы получить дополнительную информацию о тестовом сервере или завершить его работу, необходимо дважды щелкнуть на этом значке.

Фиксация и перезапуск веб-страницы полезны, но что делать, когда необходимо отследить трудно уловимую ошибку? В этих случаях понадобятся усовершенствованные возможности отладки Visual Studio, которые рассматриваются в последующих разделах.

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

Пошаговая отладка

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

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

Теперь запустите свою программу обычным образом. Когда программа достигнет точки останова, выполнение приостановится, и вы переключитесь обратно в окно кода Visual Studio. Оператор, на котором установлена точка останова, не выполнится.

На этом этапе доступно несколько возможностей. Вы можете выполнить текущую строку, нажав клавишу <F11>. Следующая строка кода будет помечена желтой стрелкой, указывая на то, что именно она будет выполнена. Вы можете продолжать это на протяжении всей программы, запуская по одной строке за раз нажатием <F11> и следуя пути выполнения кода. Или же вы можете выйти из этого режима и возобновить нормальное выполнение кода, нажав клавишу <F5>.

Вместо клавиш быстрого вызова команд вроде <F11> и <F5> можно использовать кнопки панели инструментов Debug (Отладка) в Visual Studio. В качестве альтернативы можно щелкнуть правой кнопкой мыши в окне кода и выбрать опцию из контекстного меню.

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

Если вы поместите курсор над объектом, то сможете просмотреть все его свойства, щелкнув на маленьком знаке "плюс":

Можно даже непосредственно изменить значение переменной или свойства — просто щелкните внутри окна подсказки и введите новое значение. Это позволит смоделировать сценарии, которые сложно или долго воспроизвести вручную, либо проверить специфические условия ошибок.

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

Перевести программу в режим паузы можно в любой момент, щелкнув на кнопке паузы в панели инструментов или выбрав в меню Debug (Отладка) команду Break All (Остановить все).

Слежение за переменными

В некоторых случаях может понадобиться отслеживать состояние переменной без постоянного переключения в режим паузы. В таких ситуациях более полезными оказываются окна Locals (Локальные), Autos (Автоматические) и Watch (Слежение), которые позволяют отслеживать переменные во всем приложении:

Окна для слежения за переменными

Окно	Описание
Locals	Автоматически отображает все переменные в пределах текущей процедуры, предлагая быстрый обзор важных переменных
Autos	Автоматически отображает переменные, которые система Visual Studio определила как важные для текущего оператора в коде. Сюда могут входить, например, переменные, к которым получается доступ или которые изменяются в предыдущей строке
Watch	Отображает добавленные вами переменные. Установки слежения сохраняются вместе с проектом, чтобы можно было продолжить слежение за переменными позже. Для добавления слежения щелкните правой кнопкой мыши на переменной в коде и выберите в контекстном меню пункт Add Watch (Добавить слежение); в качестве альтернативы дважды щелкните на последней строке в окне Watch и введите имя переменной

Каждая строка в окнах Locals, Autos и Watch предоставляет информацию о типе или классе переменной и ее текущем значении. Если переменная содержит экземпляр объекта, ее можно развернуть и просмотреть приватные члены и свойства.

Например, в окне Locals вы увидите переменную this, которая является ссылкой на текущий объект страницы. Если вы щелкнете на знаке "плюс" возле нее, появится полный список свойств страницы (и некоторые системные значения):

Окна Locals, Autos и Watch позволяют изменять переменные или свойства во время нахождения программы в режиме паузы. Дважды щелкните на текущем значении в столбце Value (Значение) и введите новое значение. Если не хватает какого-то окна слежения, отобразите его вручную, выбрав его в подменю Windows меню Debug.

Расширенные точки останова

Выберите в меню Debug (Отладка) команду Windows --> Breakpoints для отображения окна, в котором перечислены все точки останова в текущем проекте. Окно Breakpoints (Точки останова) предоставляет счетчик попаданий в точку останова. Дважды щелкнув на точке останова, можно переместиться в соответствующее место кода:

Окно Breakpoints можно также применять для отключения точки останова без ее удаления. Это позволяет сохранить точку останова, чтобы использовать во время тестирования позже. Точки останова автоматически сохраняются в файле решения.

Visual Studio позволяет настраивать точки останова так, чтобы они проявлялись только в случае соблюдения определенных условий. Чтобы настроить точку останова, щелкните на ней правой кнопкой мыши и выберите одну из перечисленных ниже опций:

Location

Используйте эту опцию, если хотите увидеть точный файл и строку, в которой находится данная точка останова.

Condition

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

Hit Count

Используйте эту опцию, если хотите создать точку останова, которая будет приостанавливать процесс выполнения только либо после определенного количества срабатываний (например, хотя бы после 20), либо через определенное количество срабатываний (например, через каждые 5).

Filter

When Hit

Второй вариант — указать в качестве такого действия запуск макроса Visual Studio, что позволит выполнить в IDE-среде практически любое действие.

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

Настройка инфраструктуры логгирования

Прежде чем начать писать что-то в логи, нужно настроить провайдеров логов. Для этого в метод Configure() класса Startup инжектируется сервис ILoggerFactory . Используя этот сервис можно настроить провайдеров:

Аналогичным образом добавляются и другие провайдеры. Microsoft предоставляет такие провайдеры как Microsoft.Extensions.Logging.Console , Microsoft.Extensions.Logging.Debug , Microsoft.Extensions.Logging.TraceSource , Microsoft.Extensions.Logging.AzureAppServices , Microsoft.Extensions.Logging.EventSource , Microsoft.Extensions.Logging.EventLog . Как нетрудно догадаться из названия, каждый из них имеет собственный источник для хранения логов.

Можно использовать несколько провайдеров одновременно:

Запись в лог

Для того, чтобы начать писать что-то в лог, следует инжектировать интерфейс ILogger в нужный компонент приложения. Причем в качестве generic-параметра мы можем указать категорию логгера. Например, получим доступ к логгеру в компоненте HomeController :

LogDebug()
LogTrace()
LogInformation()
LogWarning()
LogError()
LogCritical()

Попробуем записать что-нибудь в лог:

Теперь при срабатывании этого действия в консоли отладчика обязательно появится запись:

WebApplication8.Controllers.HomeController:Error: Some error occured

Если при настройке провайдеров мы настроили также вывод в консоль ( AddConsole() ), то эта же запись появится и в консоли (если мы запускаем приложение через Kestrel и консоль нам видна).

Записывать в лог можно не только обычные строки, но и структурированные данные. Для этого существуют специальные перегрузки методов LogXXX() . Запишем, например, в лог данные с идентификатором объекта:

В логе появится строка следующего содержания:

WebApplication8.Controllers.HomeController:Error: Unable to delete object with 25 key

Если провайдер поддерживает структурированные данные, то ID будет доступно как отдельное поле. Более того, поле может быть не только простым типом, но и составным объектом. Но это — отдельная тема и здесь касаться этого не будем.

Scope

Например, группировку поддерживает Microsoft.Extensions.Logging.Console . Для её использования это нужно указать явно при настройке провайдера:

Фильтрация логов

Все записи в логах разделяются по степени важности. Например, методы LogDebug() и LogInformation() записывают событие с какими-то отладочными данными. Их смысл в том, чтобы дать представление о процессах, которые происходят в приложении, но не более. С другой стороны LogWarning() , говорит о том, что в приложении произошло что-то, на что было бы неплохо обратить внимание. Наконец, LogError() или LogCritical() записывает информацию об ошибках — т.е. приложение повело себя не так, как планировалось, и на такие записи обязательно нужно обращать внимание.

Это поведение задается при помощи специального параметра:

В этом случае всё, что менее критично, чем Error или Warning будет игнорироваться для этих провайдеров.

Вот как например можно настроить провайдер для записи в консоль:

Другой способ — использовать конфигурационный файл для настройки уровней логгирования:

Конфигурационный файл в этом случае может выглядеть так:

Ещё один удобный способ настроить фильтры — это использовать пакет Microsoft.Extensions.Logging.Filter . После установки этого пакета для ILoggerFactory , появится метод-расширение WithFilter() , позволяющий настроить фильтры:

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

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

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

Метод Debugger.Launch()

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

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

В котором можете выбрать либо уже запущенную студию (у меня это 1-я строка), либо использовать новый экземпляр студии по вашему выбору.
Внимание! Если "New instance Microsoft . ", тогда весь код проекта будет не доступен. Поэтому желательно выбирать студию с отрытым вашим проектом. Теперь по поводу жизненных ситуаций, когда этот метод пригодится:

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

Метод Debugger.Break()

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

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

Output window и класс Debug.

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

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

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

Пошаговая инструкция:

Открепляем окно Ouput и перетаскиваем его в правую часть окна, закрепляя ее на фиксаторе как на картинке:

Теперь мы будем видеть вывод через Debug.Write и настроенный Debug.Trace.

Настройка Log4net и TraceAppender к нему:

По поводу того, как Debug.Write жизнь и нервы спасает, ситуации из жизненного опыта:

Атрибут DebuggerDisplayAttribute.

Представьте жизненную ситуацию, у вас имеется ссылка на массив из объектов и вам надо как то посмотреть значение его полей. Для этого вам потребуется нажимать на стрелочку напротив каждого элемента, что бы увидеть внутренние поля которые вам нужны. Если у вас 3-5 объектов то это можно проделать вручную, но представьте, что там 100 объектов, а вам надо найти тот, у которого определенное значение поля. В итоге либо писать отдельный код который бы отфильтровал вам объекты и оставит нужный. Или можно использовать замечательный атрибут DebuggerDisplayAttribute, который, в режиме отладки, покажет вам всю необходимую для вас информацию об объекте.

Постараюсь продемонстрировать работу на примере. Имеется код:

После запуска в массиве people у вас будут лежать объекты Man со случайными значениями поля возраст. Допустим ваша задача узнать, есть ли объекты с именем "Sergei" в массиве. Запускаем приложение встаем на точке останова, выделяем people жмем "Quick Watch" и видим, что для того, что бы узнать имя нам потребуется у каждого объекта отрывать поля:

По умолчанию отладчик выводит значение .ToString() объекта, он у нас не перегружен, поэтому ToString() выводит значение базового Object.ToString() выводящего имя класса. Поэтому я добавлю атрибут DebuggerDisplay к классу Man. Пример:

Запустился и в "Quick Watch" видим совершенно другую картину:

Как это работает?

Очень просто, для понимания строку "Name = , Age = " стоит представлять как string .Format( "Name = , Age = " , Name, Age ), где на место фигурных скобок < >будет подставлено значение поля с именем Name и Age. Так же можно использовать выражение и даже вызывать методы, как если бы мы работали с объектом напрямую.

Что бы стало все еще более понятно постараюсь продемонстрировать строку посложнее:

Запустившись и увидим вот такую картинку:

Таким образом можно пластично настроит вывод любой интересующей нас информации. Особенности, которые стоит всегда держать в голове:

Если свойство или поле вашего класса имеет значение NULL, а вы обратитесь к его свойству открыв окно отладчика, тогда будет NullReferenceException, который отобразится строкой. Поэтому, что бы DebuggerDisplay отображал все объекты корректно, стоит обрабатывать обращение к NULL полю.
Перед добавлением значения стоит помнить, что если обращение к свойству или методу приводит к запросу к БД или обращение к серверу, то и очевидно, что перед показом отладчик будет делать то же самое. Будьте к этому готовы.
Все изменения с полями\свойствами\объектами вызванными внутри форматированной строки останутся, как если бы вы сами это поменяли. Будьте внимательны!

Перемещение вектора исполнения в Visual Studio.

Имеется метод, допустим импорта чего либо, выполняющийся длительное время. В конце метода есть место, которое требуется отладить. Мы ставим breakpoint, запускаем импорт и в хоте отладки по F10 понимаем, что мы прошли место, которое надо было изучить более пристально. Как решить эту проблему? Пока что, если только перезапустить импорт и вновь дойти до этого места.
Допустим в импорте из пункта 1. есть условие IF+ELSE внутрь IF зайти легко, а что бы выполнилось условие ELSE требуется еще какие то сложные подготовительные действия. Можно за комментировать условие IF оставить только вызов ELSE, но хардкод это не очень удобный вариант.
Вы находитесь в методе, и хотите произвести повторную отладку, но для этого вам понадобится по новой запустить приложение, а значит затратить лишнее время на ожидание и можете банально забыть, что же вы хотели проверить.

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

Это обычное консольное приложение, на нем видно как я вектор исполнения перемещаю в нужное мне место и код продолжает выполняться, как если бы было сделано GOTO. При этом передвигаясь вперед или назад, это не откат назад или пропуск операций и остановка в нужном месте Все действия это реальные переходы, и вполне можно так пропустить инициализацию какой то переменно, перейти к обращению не инициализированной переменной, то получите NullReferenceException в 100% рабочем коде. Поэтому перед тем как перемещать стоит внимательно посмотреть является ли переход "Корректным". Если хотите пройти метод снова, то обязательно переводите исполнение на повторную инициализацию локальных переменных.

Правка кода в режиме отладки [Edit and continue].

Хочу рассказать о еще одной feature в Visual Studio, которая может упростить процесс написания кода, когда тебе надо написать работу с классом, но тебе не известно, что хранится в его полях. В этом случае написание сводится к череде:

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

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

Внимание! Код который был написан не компилируется на лету, и при проходе через него возможны визуальные искажения, не стоит на это обращать внимание, так как Visual Studio оперирует данными по смещениям и размерам методов из pdb, которые были собраны до запуска.

Палочка выручалочка "Immediate Window".

За всё время пока я занимаюсь программированием под .NET Framework я ни разу не видел, что бы кто то при мне пользовался "Immediate Window" в Visual Studio, поэтому если ты слышишь про него первый раз, то обязательно добавь его на рабочее пространство и используй! А вот как, я расскажу прям сейчас.

Появляется необходимость вызвать какой то метод доступный из текущего места.
У локальной переменной хотим заменить значение БЕЗ перезапуска приложения
Посмотреть результат выполнения
Иными словами хочется вставить и исполнить какую то временную инструкцию.

Думаете это не возможно? Вы ошибаетесь - выход это "Immediate Window". Встав на точку останова вы можете писать не просто выражения, вызывать методы, но и менять значения переменных локальных и глобальных. При этом данный код будет выполняться отдельно от вашего исходного текста программы.

Пример использования:

В самом окне работает IntelliSence поэтому проблем с именами быть не должно.
Само окно в случае, если введенное выражение возвращает какой то сложный объект, используется продвинутый Formatter, который покажет в читабельном виде все его поля.
Не обязательно указывать ";" после каждого выражения.
Очень удобно использовать когда надо вывести все поля в читабельном виде.
Стрелками "Вверх\вниз" можно подставить ранее введенные выражения.
Можно задавать значения локальных переменных

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

Остановка по требованию или Condition breakpoints.

Breakpoint пользуются все, но стоит помнить о том, что можно указать условие срабатывания точки останова. Бывает часто, что метод вызывается N раз, и требуется на K итерации проверить какой то значение. Если по каким то причинам вы не знает про Condition breakpoints то погнали!

Допустим есть код:

Наша цель, когда i будет равно 500 остановиться и узнать полученное значение от суммы со случайным числом. Если вы садомазахист, то можете поставить точку останова и 500 раз нажимать F5. Но лучшим решением будет поставить точку останова в начале метода, выбрать "Conditions. ":

В появившемся окне в поле "условие" вводим "i == 500" и если условие указано без ошибок, то по нажатию на Enter красная точка поменяет свой вид на точку с плюсом.

Запускаем программу и видим, что мы остановились на месте, когда значение i стало 500.

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

Удалённый отладчик Remote Debugger.

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

Важно знать! Что нужно ставить Remote Debugger Tools для версии вашей студии, обратную совместимость версии не гарантируется. Поэтому если у вас к примеру Visual Studio 2012, тогда нужно искать Remote Debugger для 2012.

Всю настройку описывать не буду, по адресу Remote Debugging можно получить всю интересующую информацию.

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

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

Вообще, на сегодняшний момент ни одно более или менее серьезное приложение не обходится без написания логов.

Лог (log) - это специальный журнал, в котором хранится информация о состоянии работы приложения (программы).

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

Какие записи делать в этот журнал, то есть, какую конкретно информацию записывать, определяет сам разработчик. Это могут быть сведения о том, что все работает в штатном режиме, то есть просто ежедневный мониторинг нашего приложения, или что произошла какая-то ошибка, на которую нужно максимально срочно отреагировать и устранить, и так далее.

Trace – максимально детальная информация о том, что происходит с целевым участком кода, по шагам. Например: Попытка открыть подключение к БД, успешно\неуспешно. Сколько времени заняла эта операция. Сколько времени выполнялась выборка из БД, успешно\неуспешно. Сколько записей извлечено. Какая была нагрузка на систему, сколько использовано памяти. Сколько записей прошло нужную фильтрацию. Сколько записей оказалось в результирующей выборке, куда эти записи отправились дальше. Проверка нужных значений в каждой записи.

Debug – это информация для отладки. Логирование крупных операций, менее детально, чем в Trace. Здесь мы не так подробно описываем весь процесс операции, но, тем не менее, заносим в журнал основные операции. Например: Совершено обращение к БД. Из базы выбрано N записей. Записи успешно обработаны и отправлены клиенту.

Если же в опасных участках кода мы генерируем исключение, то теперь мы также добавим запись в лог с пометкой Error.

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

Для того, чтобы начать логирование, мы подключим в наш проект платформу NLog. Это можно легко сделать посредством менеджера NuGet (прямо из Visual Studio).

Обратите внимание на конфигурационный файл NLog.config. В этом файле находятся настройки логгера (куда будут выводиться логи, формат записи логов и т.д.). Давайте настроим файл следующим образом:

Здесь мы описали два правила и цели, к которым они применяются. Мы хотим чтобы отладочная информация была записана в один файл, а информация об ошибках - в другой (в поддиректории errors). Оба лога будут писаться в текстовый файл. Также мы используем специальные теги (директивы), которые понимает NLog. На их место будут подставлены соответствующие значения в процессе выполнения. Опишем теги, которые используются у нас в конфигурации (описание всех тегов и любую другую информацию можно найти на официальном сайте проекта NLog):

Далее уже в коде объявим новый логгер (здесь код проекта приводится в сокращенном виде, исходный код всего проекта можно скачать в конце статьи):

Чаще всего следует объявлять один статичный логгер в пределах всего класса. Здесь мы посредством класса-менеджера LogManager объявили новый логгер, с которым будем работать.

Начнем логирование с уровня Trace. В методе, где мы выбираем студента по его идентификатору, давайте максимально подробно опишем как это происходит:

Теперь определим, что же нам записать на уровне Fatal. В нашем простейшем примере просто смоделируем подобную ситуацию:

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

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

На этом здесь все, давайте подведем небольшой итог. Мы изучили тему логирования в приложении. Посмотрели как правильно логировать те или иные участки кода, а также познакомились с одной из самых популярных платформ логирования – это NLog Platform, также рассмотрели ее возможности и как можно настроить генерацию логов на этой платформе.

Читайте также: