А поправьте меня, если я ошибаюсь — разве проект log4net не был заброшен 5 лет назад (по крайней мере этой датой датируются последние багфиксы на официальном сайте)? Я неоднократно встречал людей, отдающих предпочтение NLog на основании того, что последний активно развивается, в отличии от log4net.
4 месяца назад — фикс одного плагина в пару строк кода. Последний фикс ядра — 20 месяцев назад (тоже пару строк), до этого — 3 года назад. Последний стабильный билд — 4 года назад.
Да, я сразу оговорился, что менять схему логирования — задача иного уровня. По-хорошему необходимо более чётко продумывать логирование/мониторинг (БД, типы сообщений и т.п.).
хорошо так. но есть пара замечаний:
1. методы помещения в очередь [как он у вас называется?] и ThreadProc лучше сделать на Monitor.Pulse() | Monitor.Wait(), чтобы не засыпать в цикле на длинную константу[?] QueueEmptyCheckTimeoutInMilliseconds
2. log4net, конечно, мощь. но уж очень монструозная. и как говорили коментаторы выше – подзаброшенная.
1. Да, Вы абслоютно правы, с Monitor Pulse/Wait лучше должно быть. Сейчас просто в lock (syncObject) делается Enqueue у Queue, а QueueEmptyCheckTimeoutInMilliseconds по умолчанию 10мс.
2. Да уж. Странно, что Apache Foundation не занимается развитием библиотеки.
Хмм, а я использую log4net… везде… и ColoredConsoleAppender, который вообще рулит :)
Ну и что что никто ничего к библиотеке не дописыват? Значит она уже идеальна!
Главное пользоваться чем-нибудь типа Common.Logging (wrapper над популярным логирующими системами), чтобы не было мучительно больно при переходе с «теперь уже неустрающего» фрейморка на другой. Всё меняется, понадобится подобная функционально, как я описал, а окажется, что без переписывания библиотеки не выйдет…
Расширяем log4net. Конкурентное логирование