Random thoughts on software engineering, tabletop gaming, IoT, politics, blockchain, and other topics.
I have made significant changes in the organisation of the Essential.Diagnostics project; although none of the actual implementations have changed, the project has been split into separate packages for each trace listener, available via NuGet.
The packages are available on NuGet (Essential.Diagnostics), and the source code on CodePlex (Essential.Diagnostics).
The project also has a new logo:
This was originally going to be some guideline instructions for a CodePlex project, Essential.Diagnostics that I work on, but it ended up being more an opinion piece so I thought it would fit better on a blog.
There are several trace listeners (loggers) in the .NET Framework that can produce XML output. Outputting to XML results in more complex (verbose) files than, say, a simple text file output, but usually has the benefit of being better processed by tools, correlated across tiers, etc.
There are three main XML listeners, plus one extension in Essential.Diagnostics:
Examples of how to configure and use each one (used to produce the output below) is provided in the Essential.Diagnostics project.
Continue reading XML Logging in the .NET Framework(13 min read)
I added a comparison of the major logging/tracing frameworks for .NET to the CodePlex site for Essential.Diagnostics, to demonstrate how System.Diagnostics stacks up against log4net, NLog and the Enterprise Library.
I also added a performance comparison (the source code is in the CodePlex project if you want to verify the results).
Look at the results for yourself, but I think System.Diagnostics does okay -- and the extensions in Essential.Diagnostics (plus others such as Ukadc.Diagnostics and UdpPocketTrace) fill out the gaps compared to log4net and NLog. Similarly on the performance side, all have very little overhead (NLog is a winner on overhead, but does relatively worse on actually writing the messages to a log file).
What about the Enterprise Library Logging Application Block? Well, I just don't think it does well compared to the others. Sure it was a lot better than .NET 1.0 System.Diagnostics, but a lot of that was added in .NET 2.0 System.Diagnostics (such as multiple sources). In some cases it is worse than what is currently available in the standard framework -- e.g. no delayed formatting. This shows up in the performance figures which indicate several magnitudes greater overhead than any of the other frameworks!
I'm obviously biased, but I really think that the best solution is to stick with the standard, out-of-the-box, System.Diagnostics, extended where necessary to fill any gaps (Essential.Diagnostics, etc, for additional listeners, filters & formatting).
P.S. Also check out my guidance on Logging Levels.
According to MSDN "in Microsoft SharePoint Foundation 2010 the preferred method of writing to the Trace Logs is to use the SPDiagnosticsServiceBase class" (http://msdn.microsoft.com/en-us/library/ff512746.aspx).
MSDN also provides some guidance on the trace and event log severity levels to use (http://msdn.microsoft.com/en-us/library/ff604025.aspx), however the WriteEvent() and WriteTrace() methods use slightly different enums; the diagnostics logging configuration in Central Administration is slightly different again, and then you have a third set of values accessed by the PowerShell command Get-SPLogEvent.
The table below shows the mapping of levels from these different sources.
Despite the complicated mapping, in general I think things go in the right direction with events writing to the event log and trace log at the same time, and having a high trace level. The distinction between event logging and trace information is also good, with independently set thresholds.
| EventSeverity | EventLogEntryType | TraceSeverity | ULSTraceLevel | ULSLogFileProcessor .TraceLevel |
| None = 0 | None = 0 | 0 (None) | Unassigned = 0 | |
| ErrorServiceUnavailable = 10 | Error | 1 | Critical = 1 (or ErrorCritical) | |
| ErrorSecurityBreach = 20 | ||||
| ErrorCritical = 30 | ||||
| Error = 40 | ||||
| Exception = 4 | ||||
| Assert = 6 | ||||
| Warning = 50 | Warning | 8 | Warning = 8 | |
| FailureAudit = 60 | ||||
| Unexpected = 10 | Unexpected = 10 | Unexpected = 10 | ||
| Monitorable = 15 | Monitorable = 15 | Monitorable = 15 | ||
| SuccessAudit = 70 | Information | 18 | Information = 18 | |
| Information = 80 | ||||
| Success = 90 | ||||
| Verbose = 100 | ||||
| High = 20 | High = 20 | High = 20 | ||
| Medium = 50 | Medium = 50 | Medium = 50 | ||
| Verbose = 100 | Verbose = 100 | Verbose = 100 | ||
| VerboseEx = 200 | VerboseEx = 200 | VerboseEx = 200 |
Essential.Diagnostics is a library of additional trace listeners and other bits for the .NET Framework System.Diagnostics trace logging.
It doesn’t change the way you write log statements (you still use TraceSource), but fits into the built-in extension points to add functionality (mostly additional trace listeners and filters).
From the project description:
“Essential.Diagnostics contains additional trace listeners, filters and utility classes for the .NET Framework System.Diagnostics trace logging. Included are colored console (that allows custom formats), SQL database (including a tool to create tables) and in-memory trace listeners, simple property and expression filters, activity and logical operation scopes, and configuration file monitoring.”
The intention is to round-out System.Diagnostics with additional capabilities so that it can be compared to alternative 3rd party logging systems (NLog, log4net, Common.Logging, and even Enterprise Library).
Note that the library is intentionally much lighter than Enterprise Library; rather than an overhaul of the logging mechanism itself the library is mainly meant to provide additional trace listeners.
I put the source code up a few days ago, but only recently finished the packaging scripts for the downloads.
With the recent release of NuPack NuGet, I have also spent an additional bit of time and set it up as a NuGet package.