Есть много похожих вопросов здесь, на SO:
Вы пропустили несколько часто используемых каркасов журналирования.Вот список часто используемых платформ, некоторые из которых вы перечислили:
Абстракции ведения журнала:
Дополнения System.Diagnostics:
Other
Несколько других каркасов ведения журналов из codeplex (которые я виделупоминается здесь в SO):
Почему вы можете выбратьодин над другим?Это сложный вопрос.Во многом это личное предпочтение.Отчасти это техническое (или особенное) превосходство.
Одним очевидным недостатком любой среды ведения журналов (особенно сторонней) является качество поддержки.Что делать, если у вас есть проблемы с log4net, NLog, Common.Logging и т. Д.?Сможете ли вы получить исправления от разработчиков этих фреймворков?Это может быть не очень важно, так как исходный код доступен для этих платформ.Однако вы можете предпочесть НЕ «наследовать» исходное дерево только для того, чтобы исправить или добавить расширение.Я скажу, что фреймворки настолько расширяемы, что многие улучшения могут быть добавлены через обычные точки расширения.
Если вы читаете ссылки, которые я разместил выше, я думаю, что это будет справедливо, основываясь исключительно наОбъем благоприятных упоминаний о том, что log4net будет явным «победителем».Это будет упоминаться чаще как исторический фаворит и то, что многие люди будут использовать в будущем.
У NLog есть свои сторонники, просто у него, кажется, нет проникновения или понимания на высшем уровне, как у log4net, хотя они очень похожи.Возможности NLog очень похожи на log4net, и у него есть дополнительное преимущество, поскольку он недавно прошел значительный цикл разработки.
Enterprise Library часто рекламируется как хороший выбор, но почти так же часто рекламируется как ужасный выбор.,Может быть, какая-то его негативная репутация, возможно, не очень хорошие ранние версии?Может, сейчас лучше?
System.Diagnostics часто рекомендуется в качестве разумного выбора, по крайней мере, с тремя сильными преимуществами: отсутствие сторонней зависимости, многие компоненты Microsoft снабжены System.Diagnostics, его легко расширить (предположительно, для добавления некоторых функций, которыеуже присутствует "бесплатно" в таких фреймворках, как log4net и NLog?).Если вы используете System.Diagnostics, я думаю, что консенсус будет (как и моя рекомендация) использовать объекты TraceSource, а не Trace.WriteLine / Debug.WriteLine.
Обратите внимание, что System.Diagnostics и WCF хорошо работают вместе.Трафик сообщений WCF можно регистрировать с помощью System.Diagnostics, и WCF также будет распространять информацию о действиях System.Diagnostics (System.Diagnostics.CorrelationManager.ActivityId) через пограничные вызовы службы WCF.
Я не уверен, что log4net должен продолжать сохранять свой наиболее предпочтительный статус. Как уже было отмечено здесь, в SO, log4net, похоже, в последнее время не проходит большую разработку (обратите внимание, что я думаю, что "log4net is dead" - преувеличение), в то время как NLog 2.0 в настоящее время находится в бета-версии с окончательный выпуск ожидается в первом квартале 2011 года (обновление: NLog 2.0 был выпущен 17 июля 2011 года). Делает ли это NLog явно лучшим выбором, чем log4net? Я не знаю, но я думаю, что, условно говоря, NLog должен получать как минимум одинаковое внимание при выборе между этими двумя и, вероятно, должен быть предполагаемым фаворитом для новой разработки, по крайней мере, до тех пор, пока разработка log4net не покажет больше признаков жизни.
log4net и NLog предлагают очень гибкие опции конфигурации. Они позволяют вам иметь очень тонкую гранулярность в определении ваших операторов регистрации (по «стандартной» схеме определения регистратора для каждого типа). Они также позволяют легко расширять библиотеки, позволяя вам создавать свои собственные объекты «назначения журналирования» (log4net Appenders и NLog Targets) и объекты «форматирования» (конвертеры шаблонов log4net и NLog LayoutRenderers).
Помимо выбора структуры ведения журнала, некоторые (многие?) Выступают за изоляцию кода вашего приложения от жесткой зависимости от конкретной среды ведения журнала с помощью уровня абстракции. Это может принять форму вашего собственного интерфейса ILogger, который вы реализуете, возможно, поверх существующего фреймворка. В будущем вы могли бы изменить каркас, внедрив свой ILogger в другом каркасе. Или вы можете использовать DI / IoC для добавления "ILogger" в ваш код. Многие инфраструктуры DI / IoC предоставляют встроенную абстракцию ILogger, которую можно настроить на использование log4net, NLog или Enterprise Library или вы можете написать собственную реализацию ILogger и внедрить ее). Кому какое дело до реализации? Другой способ изолировать ваш код от жесткой зависимости от конкретной среды ведения журналов - это использовать существующую структуру абстракции ведения журнала, такую как Common.Logging или SLF. Преимущество заключается в том, что, опять же, ваше приложение не зависит от конкретной структуры ведения журналов. Однако некоторые скажут, что вы только что обменяли одну зависимость (в каркасе логирования) на другую (каркас абстракции логирования).
Еще две заметки об абстракции логирования:
Хорошая абстракция журналирования должна позволять вам захватывать выходные данные из разных каркасов журналирования в одном и том же выходном файле. Common.Logging называет это «мостом». Допустим, вы написали приложение с использованием Common.Logging, поддержанное NLog. Теперь скажите, что вы используете стороннюю библиотеку классов, которая написана с использованием log4net напрямую. С помощью системы мостов вы можете захватить выходные данные log4net (через пользовательский аппендер) и перенаправить их через Common.Logging, чтобы выходные данные журналов сторонней библиотеки классов можно было просматривать в контексте выходных данных журналов вашего приложения.
Использование абстракции ведения журнала также позволяет вам тестировать каркасы ведения журналов во время разработки. Вы могли бы начать думать, что log4net - это тот путь, но вы хотите оставить себя открытым для попытки NLog. Используя абстракцию логирования, относительно легко переключаться между ними. В конечном счете, вы можете выбрать, какую среду ведения журналов, но в то же время вы смогли написать множество кода, который никак не зависит от конкретной среды ведения журналов.
Другая причина, по которой вы можете выбрать одну платформу вместо другой, - это среда, в которой вы работаете. Если вы уже используете часть Enterprise Library, этого может быть достаточно, чтобы подтолкнуть вас к использованию ведения журнала Enterprise Library.
Что если вы разрабатываете в Silverlight? Вы можете использовать что-то вроде Clog - часть кальция . Вы также можете использовать NLog 2.0, совместимый с Silverlight и WP7.
Аддоны System.Diagnostics (Ukadc.Diagnostics, Essential.Diagnostics).Это не каркасы журналирования как таковые.Скорее, они представляют собой наборы полезных объектов и точек расширения, которые можно использовать с существующей платформой System.Diagnostics.На мой взгляд, одна из лучших вещей, которую добавляет каждый из этих дополнений, - это возможность форматировать выходные данные журналов, подобно тому, как вы можете форматировать их с помощью log4net и NLog.Я не использовал Essential.Diagnostics, но я экспериментировал с Ukadc.Diagnostics и думаю, что это действительно круто.Даже легко написать свои собственные «жетоны форматирования».
Я не знаю, полностью ли это ответил на ваш вопрос (в любом случае, он довольно широкий), но я думаю, что здесь есть много пищи для размышлений.