Comments 21
Неплохо, надо будет попробовать. Только не вижу смысла писать свой логгер, может лучше взять что-нибудь готовое? Log4net например.
Собственно никто не мешает засунуть в свой логгер готовое решение. Я показал на примере велосипеда, потому как он проще для понимания.
Или NLog, там как раз я видел аналогичный функционал (консоль + раскраска сообщений), правда пока не пользовался. А теперь, после просмотра скриншота, наверное, попробую ) Автору спасибо, полностью поддерживаю его в деле использования логирования на всю катушку, в любых приложениях.
Возможно я и не прав, но ИМХО такую вещь как логгер можно написать за час-два, то есть за то же время, которое будет потрачено на поиск готового решения в интернете и на то, чтоб разобраться с ним. И это при условии отсутствия багов и подводных камней. Конечно, если вам нужен ORM или MVC-фреймворк, или даже специфический тип логгера, то разумнее взять готовое решение, но если достаточно писать сообщения в файл и выводить на консоль, то зачем же уподобляться пресловутым программистам на Delphi из анекдота про льва и пустыню?
Замечательный материал, но, имхо, позиционирование неправильное. Консоль/лог идеально подходят для более глубокой отладки и поиска мигрирующих багов, а это, как правило, компетенция профессиональных разработчиков. Большинство же багов весьма случайны и видны либо по конкретному исключению, либо по беглому анализу стека вызовов, и удобнее интерфейса дебагерра для начинающих разработчиков здесь ничего нет.
Ну я вот чуть больше года работаю и тем не менее использую консоль с первых дней работы — чертовски удобная вещь при работе со сложной бизнес-логикой, с которой мне доводилось работать. Наверное мне просто повезло с тем, что сразу доверили сложную работу.
Исправил текст на «Все, что написано ниже, скорее всего пригодится новичкам, но и опытные разработчики смогут почерпнуть для себя что-нибуть интересное.»
Исправил текст на «Все, что написано ниже, скорее всего пригодится новичкам, но и опытные разработчики смогут почерпнуть для себя что-нибуть интересное.»
Привыкать к прелестям интегрированных отладчиков — тоже не очень. Потому что рано или поздно в жизни любого разработчика может возникнуть ситуация, когда отладка в таком удобном режиме будет недоступна. И в этом случае выручает логгер ) Кстати, при отладке многопоточных приложений механизм логирования в любом случае необходим.
Поскольку мы не хотим, чтобы консоль была видна во время нормальной работы приложения на сервере, код, инициализирущий ее, мы заключили в директиву условной компиляции
В данном случае удобнее было бы использовать атрибут Conditional, не находите?
Мне так удобнее — во первых решарпер выделяет такие куски кода серым цветом и сразу понятно, что код не будет компилироваться, а во вторых если забыть определить CONSOLE в проекте, который дергает метод (а у меня он находится в другом проекте), то работать атрибут не будет. В принципе это на любителя и как кому больше нравится.
Еще вместо lock-а на typeof() можно декларативно указать синхронизированность метода.
Ну и вообще, есть такая штука, как Trace Listeners.
И можно прямо из config-файла указывать, куда будет направляться вывод сообщений, в том числе и в ConsoleTraceListener.
Хотя, свой велосипед, конечно, иногда удобнее :)
Ну и вообще, есть такая штука, как Trace Listeners.
И можно прямо из config-файла указывать, куда будет направляться вывод сообщений, в том числе и в ConsoleTraceListener.
Хотя, свой велосипед, конечно, иногда удобнее :)
Я бы посоветовал использовать DebugView от Mark Russinovich'a.
А зачем определять CONSOLE, есть уже готовые TRACE и DEBUG?
А зачем определять CONSOLE, есть уже готовые TRACE и DEBUG?
Хотя бы за тем, что иногда может быть необходимо отключить консоль без отключения TRACE и DEBUG — консоль довольно сильно замедляет работу приложения при большом обьеме выводимых данных.
А какие плюсы в отладке веб-приложений у этого метода, по сравнению с Debug консолью. Методы класса System.Diagnostics.Debug, например, помечены специальным атрибутом Conditional и, соответственно, не попадают в Release сборки приложения. А подсветка легко реализуется через DebugView.
Про DebugView впервые узнал сегодня :) Как-то вот так случилось. Пощупал, неплохо, но обычная консоль пока мне нравится больше — наверное сказывается привычка. Спасибо, теперь буду знать и по возможности использовать.
Добавил упоминание про DebugView в статью.
Добавил упоминание про DebugView в статью.
DebugView не дифференцирует процессы, поэтому в эту свалку сообщений может влезть кто угодно. Так что придется к каждому сообщению дописывать какой-нибудь опознавательный знак.
Sign up to leave a comment.
Использование консоли при отладке ASP.Net приложений