Использование консоли при отладке ASP.Net приложений

[@Gangsta]

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

[@mace]

Собственно никто не мешает засунуть в свой логгер готовое решение. Я показал на примере велосипеда, потому как он проще для понимания.

[@Gangsta]

Ну так суть идеи не логгер, а использование консоли. Если бы статья называлась «как написать свой логгер», тогда было бы понятно. Но все равно, молодец!

[@mace]

Спасибо :)

[@elw00d]

Или NLog, там как раз я видел аналогичный функционал (консоль + раскраска сообщений), правда пока не пользовался. А теперь, после просмотра скриншота, наверное, попробую ) Автору спасибо, полностью поддерживаю его в деле использования логирования на всю катушку, в любых приложениях.

[@mace]

Возможно я и не прав, но ИМХО такую вещь как логгер можно написать за час-два, то есть за то же время, которое будет потрачено на поиск готового решения в интернете и на то, чтоб разобраться с ним. И это при условии отсутствия багов и подводных камней. Конечно, если вам нужен ORM или MVC-фреймворк, или даже специфический тип логгера, то разумнее взять готовое решение, но если достаточно писать сообщения в файл и выводить на консоль, то зачем же уподобляться пресловутым программистам на Delphi из анекдота про льва и пустыню?

[@pieceofsummer]

> такую вещь как логгер можно написать за час-два
«но зачем?» ©

Еще раз рекомендую обратить внимание на Trace Listeners.
Они удобные и гибкие с точки зрения настройки (управление на уровне файла конфигурации), родные для фреймворка и удовлетворяют 95% запросов по части отладки и логгинга.

[@habralan]

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

[@mace]

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

[@elw00d]

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

[@pieceofsummer]

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

В данном случае удобнее было бы использовать атрибут Conditional, не находите?

[@mace]

Мне так удобнее — во первых решарпер выделяет такие куски кода серым цветом и сразу понятно, что код не будет компилироваться, а во вторых если забыть определить CONSOLE в проекте, который дергает метод (а у меня он находится в другом проекте), то работать атрибут не будет. В принципе это на любителя и как кому больше нравится.

[@pieceofsummer]

Еще вместо lock-а на typeof() можно декларативно указать синхронизированность метода.

Ну и вообще, есть такая штука, как Trace Listeners.
И можно прямо из config-файла указывать, куда будет направляться вывод сообщений, в том числе и в ConsoleTraceListener.

Хотя, свой велосипед, конечно, иногда удобнее :)

[@mace]

Спасибо, я как-то забыл про [Synchronization]

[@pieceofsummer]

Только [MethodImpl].
[Synchronization] — это для ремоутинга.

[@mace]

Ага, уже понял :) Пасиб.

[@new_s]

Я бы посоветовал использовать DebugView от Mark Russinovich'a.
А зачем определять CONSOLE, есть уже готовые TRACE и DEBUG?

[@mace]

Хотя бы за тем, что иногда может быть необходимо отключить консоль без отключения TRACE и DEBUG — консоль довольно сильно замедляет работу приложения при большом обьеме выводимых данных.

[@dipyalov]

А какие плюсы в отладке веб-приложений у этого метода, по сравнению с Debug консолью. Методы класса System.Diagnostics.Debug, например, помечены специальным атрибутом Conditional и, соответственно, не попадают в Release сборки приложения. А подсветка легко реализуется через DebugView.

[@mace]

Про DebugView впервые узнал сегодня :) Как-то вот так случилось. Пощупал, неплохо, но обычная консоль пока мне нравится больше — наверное сказывается привычка. Спасибо, теперь буду знать и по возможности использовать.
Добавил упоминание про DebugView в статью.

[@pieceofsummer]

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