An improved API on top of System.Diagnostics
Adds support for dynamic runtime configuration of trace sources, hierarchical trace sources and testability.
PM> Install-Package System.Diagnostics.Tracer
Just like for TraceSource
, the recommended way to retrieve a
tracer for your code is to do so via a static readonly field:
public class MyClass {
static readonly ITracer tracer = Tracer.Get<MyClass>();
public MyClass() {
tracer.Info("Initialized my class!");
}
}
Built-in support for using Service Trace Viewer, including activity tracing:
using (var activity = tracer.StartActivity("Uploading")) {
tracer.Info("10% done");
...
}
When exceptions are traced, any additional data in the Exception.Data
dictionary is also exposed to the viewer.
One of the key benefits of leveraging the Tracer
is that configuration
can happen dynamically at run-time, via the Tracer.Configuration
, such
as setting trace levels and adding/removing trace listeners:
// Add a manually configured trace listener to the entire 'Contoso' system
Tracer.Configuration.AddListener ("Contoso", new XmlWriterTraceListener(xml));
// Tune up logging for an entire sub-system
Tracer.Configuration.SetTracingLevel ("Contoso.Payments", SourceLevels.All);
// Get the underlying TraceSource if needed
TraceSource source = Tracer.Configuration.GetSource("Contoso");
// Turn on logging for all sources retrieved via Tracer
Tracer.Configuration.SetTracingLevel ("*", SourceLevels.Warning);
The wildcard trace source allows system-wide configuration of sources retrieved
via the Tracer
, since all hierarchical sources inherit from it automatically.
The System.Diagnostics.TraceSource
is almost enough for trivial
tracing. It's what .NET itself uses all over the place even. There
are a few shortcomings though:
- Run-time configuration: can't change trace level and add/remove
listeners unless the specific
TraceSource
instance used by the code is exposed directly. - Inheriting configuration: can't easily turn on tracing for an entire application module or namespace unless every class in it is using the same trace source. So you have to think about tracing scopes up-front, and can't fine-tune later.
- Testing is s harder because of both points above.
- Correlating activities is non-trivial and error prone (issuing Start/Stop/Transfer calls appropriately)
This project (the Tracer
from now on) provides a solution to all three
issues, while still leveraging the built-in TraceSource
class. This
means you're not opting out of .NET core tracing for something totally
new and unproven. Essentially, Tracer
provides just a slightly improved
API that ultimately simply extends the built-in TraceSource
.
This means that everything down to configuring sources via config files works as usual, yet you gain run-time configuration of even built-in WCF/WPF/other sources (you can try for example the "System.Windows.Markup" in a WPF app). In addition, integration with the Service Trace Viewer is vastly improved for activity tracing as well as exception reporting.