Wann sollte ich Tracing vs Logger.NET, Enterprise Library, log4net oder Ukadc.Diagnostics verwenden?

Gibt es viele ähnliche Fragen hier SO:

• Logging best practices
• log4net versus TraceSource
• Silverlight-Logging-framework und/oder best practices
• log4net vs. Nlog
• Was ist der Punkt, der eine logging-Fassade?
• C# Einloggen. Was sollte ich verwenden?

Verpasste mehrere Häufig verwendete logging-frameworks. Hier ist eine Liste von Häufig verwendeten frameworks, von denen einige aufgeführt:

• System.Diagnostik
• log4net
• NLog
• Enterprise Library
• Das Objekt Kerl

Protokollierung Abstraktionen:

• Common.Protokollierung
• SLF

System.Diagnostik addons:

• Ukadc.Dianostics
• Essentiell.Diagnostik

Anderen

• Elmah

Ein paar andere logging-frameworks von codeplex (, die ich gesehen habe hier erwähnt, SO):

• CuttingEdge.Protokollierung
• Springschwänze

Warum könnten Sie wählen einen über den anderen? Das ist eine schwierige Frage. Viel ist es persönliche Präferenz. Einigen ist es der technische (oder feature) überlegenheit.

Einen offensichtlichen Nachteil jeder logging-framework (insbesondere Dritter) ist die Qualität der Unterstützung. Was ist, wenn Sie ein Problem haben mit log4net, NLog, Gemeinsam.Protokollierung, etc? Werden Sie in der Lage zu bekommen ein fix von den Entwicklern dieser frameworks? Dies ist möglicherweise nicht enorm wichtig, da der source-code ist verfügbar für diese Modelle. Allerdings könnten Sie es vorziehen, NICHT zu "Erben" den source-tree, nur um ein fix oder fügen Sie eine Verbesserung. Ich werde sagen, dass die frameworks sind so erweiterbar, dass viele Erweiterungen Hinzugefügt werden könnten normal über die Erweiterungs-Punkte.

Wenn du die links liest, die ich oben gepostet, ich denke, es ist fair zu sagen, nur basierend auf das Volumen der günstigen erwähnt, dass log4net wäre der klare "Gewinner". Es wird erwähnt, häufiger als die historische Protokollierung Lieblings-und was würden viele Menschen wählen, um voran zu gehen.

NLog hat seine Anhänger, es funktioniert einfach nicht scheinen, um das eindringen, oder "top of mind" Bewusstsein, dass log4net funktioniert, obwohl Sie sehr ähnlich sind. NLog ist die Fähigkeiten sind sehr ähnlich zu log4net und es hat den zusätzlichen Vorteil, dass sich durch eine bedeutende Entwicklung Zyklus vor kurzem.

Enterprise Library wird oft angepriesen als eine gute Wahl, aber fast ebenso oft angepriesen als eine schreckliche Wahl sein. Vielleicht etwas von seinem negativen Ruf ist vielleicht nicht so gut frühe Versionen? Vielleicht ist es jetzt besser?

System.Diagnose wird oft empfohlen, da eine vernünftige Wahl mit mindestens drei starke Vorteile: keine Dritte Partei, die Abhängigkeit, die viele Microsoft-Komponenten instrumentiert mit System.Diagnose, ist es leicht erweiterbar ist (vermutlich, fügen Sie einige Funktionen, die bereits vorhanden sind "kostenlos" in den frameworks log4net und NLog?). Wenn Sie mit System.Diagnose, ich denke, der Konsens wäre (wäre meine Empfehlung) verwenden TraceSource-Objekte anstelle von Trace.WriteLine - /Debug.WriteLine.

Beachten Sie auch, dass System.Diagnostik und WCF arbeiten gut zusammen. WCF-Nachricht kann der Datenverkehr protokolliert werden, mit System.Diagnostik und WCF wird auch übertragen-System.Diagnostik, Aktivitäts-Informationen (System.Diagnostik.CorrelationManager.ActivityId) über WCF-Dienst-Grenze fordert.

Bin ich mir nicht so sicher, dass log4net sollte auch weiterhin beibehalten zu seinen am meisten bevorzugten status. Wie bereits an anderer Stelle erwähnt hier ALSO an, log4net scheint nicht zu im eine Menge Entwicklung vor kurzem (beachten Sie, dass ich denke "log4net ist tot" ist eine übertreibung), während NLog 2.0 ist derzeit in der beta mit der final release voraussichtlich im 1. Quartal 2011 (Update: NLog 2.0 veröffentlicht wurde on Jul 17, 2011). Dies macht NLog eine offensichtlich bessere Wahl als log4net? Ich weiß nicht, aber ich denke, dass, relativ gesehen, NLog erhalten sollten, die mindestens gleichberechtigte Berücksichtigung bei der Wahl zwischen den beiden und, wahrscheinlich, sollte der vermeintliche Favorit für die neue Entwicklung, zumindest bis log4net Entwicklung zeigt zunehmend Anzeichen von Leben.

log4net und NLog beide bieten sehr flexible Konfigurations-Optionen. Sie ermöglichen eine sehr feine Granularität bei der definition von log-statements (von den "standard" - Muster zu definieren, die einen logger pro Typ). Sie erlauben auch für die einfache Erweiterung der Bibliotheken, die von den Studierenden ermöglichen, Ihre eigenen "logging-Ziel" - Objekte (log4net Appenders und NLog Ziele) und "Formatierung" - Objekte (log4net Muster-Wandler und NLog LayoutRenderers).

Abgesehen von einem logging-framework der Wahl, einige (viele?) Fürsprecher für die Dämmung Ihrer Anwendung code aus eine harte Abhängigkeit auf ein bestimmtes logging-framework durch die Verwendung einer Abstraktionsschicht. Dies kann nehmen die form Ihrer eigenen ILogger-Schnittstelle, die Sie implementieren, vielleicht auf einem vorhandenen framework. In der Zukunft, Sie könnte sich ändern, Rahmenbedingungen durch die Umsetzung Ihrer ILogger über einen anderen Rahmen. Oder, könnten Sie mit DI/IoC zu injizieren "ILogger" in Ihrem code. Viele DI/IoC-frameworks bieten eine eingebaute ILogger Abstraktion kann so konfiguriert werden, um log4net, NLog, oder in der Enterprise-Bibliothek oder Sie können schreiben Sie Ihre eigenen ILogger Umsetzung und injizieren). Wer kümmert sich, was die Umsetzung ist? Ein weiterer Weg, um isolieren Sie den code vor eine harte Abhängigkeit auf ein bestimmtes logging-framework ist durch die Nutzung eines bestehenden logging-abstraction-framework wie Üblich.Anmeldung oder SLF. Der Vorteil ist, dass, wieder, Ihre Anwendung ist nicht davon abhängig, dass ein bestimmtes logging-framework. Jedoch, einige würden sagen, Sie haben einfach gehandelt eine Abhängigkeit (auf einen logging-framework) für ein anderes (Protokollierung Abstraktion framework).

Zwei weitere Hinweise zu Protokollierung Abstraktion:

1. Eine gute logging-Abstraktion sollte Ihnen ermöglichen, zu erfassen Ausgang von verschiedenen logging-frameworks in der gleichen Ausgabe-Datei. Common.Protokollierung bezeichnet dies als "bridging". Sagen, dass Sie geschrieben haben, eine app, mit Gemeinsamen.Protokollierung, unterstützt durch NLog. Jetzt sagen Sie, dass Sie mit einem Drittanbieter-Bibliothek-Klasse geschrieben, mit log4net direkt. Mit einer bridging-system, können Sie erfassen die log4net-Ausgang (über eine eigene appender) und leiten es durch Gemeinsame.Protokollierung, so dass der Dritte-Klasse-Bibliothek logging-Ausgabe kann eingesehen werden im Kontext Ihres app-logging-Ausgabe.

2. Verwendung eines logging-Abstraktion, die auch ermöglicht es Ihnen, "Probefahrt" logging-frameworks bei der Entwicklung. Sie könnte beginnen zu denken, dass log4net ist, Weg zu gehen, aber Sie wollen zu verlassen, sich selbst zu öffnen versucht, NLog. Mit einer Protokollierung von Abstraktion, es ist relativ leicht zu wechseln Sie zwischen den beiden. Letztlich, Sie können die Wahl treffen, welches logging-framework, aber in der Zwischenzeit, dass Sie in der Lage zu schreiben Berge von code, der ist NICHT darauf angewiesen, in irgendeiner Weise auf ein bestimmtes logging-framework.

Einen anderen Grund, dass Sie können wählen, ein framework über eine andere ist das Umfeld, in dem Sie arbeiten. Wenn Sie bereits mit einem Teil der Enterprise Library, das ist vielleicht genug, um push zu nutzen, Enterprise Library logging.

Was ist, wenn Sie die Entwicklung in Silverlight? Sie können wählen, zu verwenden, so etwas wie Clog - Teil aus Calcium. Sie können auch wählen, zu verwenden NLog 2.0, was ist Silverlight UND WP7 kompatibel.

System.Diagnostik addons (Ukadc.Diagnostik Unerlässlich.Diagnostik). Dies sind keine logging-frameworks per se. Eher, Sie repräsentieren Sammlungen von nützlichen Objekten und Erweiterung der Punkte, die verwendet werden können mit dem bestehenden System.Diagnostics framework. Eines der besten Dinge, die, meiner Meinung nach, dass alle diese addons hinzufügt, ist die Fähigkeit, formatieren Sie Ihre logging-Ausgabe, die ähnlich wie die, die Sie formatieren können, es mit log4net und NLog. Ich habe nicht verwendet, Essentiell.Diagnose, aber ich habe experimentierte mit Ukadc.Diagnostik und glaube, dass es wirklich cool. Es ist sogar leicht zu schreiben, Ihre eigenen "Formatierung Token".

Ich weiß nicht, ob diese vollständig beantwortet deine Frage (die ziemlich Breite sowieso), aber ich denke, dass es viel Nahrung für Gedanken hier.

InformationsquelleAutor der Antwort wageoghe

Nur um ein paar Dinge gelernt, von der Microsoft Build-Konferenz 2013:

• Log4NET unter Last hat Sie in eine Datei schreiben vor allem, weil dieser Vorgang synchron ist. Es ist möglich, Streit-und Zeitüberschreitungen bei bestimmten Bedingungen. Dies kann überprüft werden mit dem Einsatz von AppDynamics oder einem ähnlichen Programm.

• NLog nicht umsetzen queueing-also unter Last, die IO-Aufrufe-stack.

• Laut Microsoft, die ETW verwendet kernel-ring-Puffer, die hoch effizient ist. .NET 4.5, und die Ereignis-Log-Rahmen kombiniert mit Semantic Logging Application Bock (AKA PLATTE)wird dies sehr viel effizienter.

InformationsquelleAutor der Antwort CHI Coder 007

Blick auf die NetLog.Logging-Paket auf GitHub, es ist meine Schöpfung. Es hat eine monitoring-app, und folgt dem java.util.die Protokollierung von API-Paradigma, weil es das ist, was ich mag zu verwenden. Es hat eine spin-lock-für den Zugang zu "schreiben", und der lock-Halter schreibt alle Datensätze in der Warteschlange, bis zu einer Grenze, bevor er sich auf. Dies wird für die Protokollierung werden weniger Konflikte basierte I/O und stellt einen guten Kompromiss dar.

InformationsquelleAutor der Antwort Grwon