Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Clone this wiki locally
Hierarchical tracing was made most famous by log4net, and means that trace destinations and levels can be configured according to coarse or fine grained application areas as neeeded.
If you retrieve a logger for a type named MyApp.Commands.MyCommand (with
Tracer.Get<MyCommand>()), you end up with four potential configuration areas in Tracer:
*: this wildcard area allows to set up a catch-all configuration for every component using Tracer on the given AppDomain.
MyApp: this typically would be the root namespace of all your app/company components, and makes for a good place to split your own components logging from third-party ones.
MyApp.Commands: this source would allow you to bump or redirect the logging for all commands in the app, without getting noise from other app areas.
MyApp.Commands.MyCommand: if you need to diagnose a particular class, you can increase its logging level directly without increasing it for any other source.
The SystemDiagnostics tracer implementation adds support for this very useful feature on top of the .NET built-in TraceSource. This allows you for example to set up a general destination for logs at the application root source (i.e.
MyApp), and allow run-time dynamic increasing of the level for particular areas as needed (i.e. something isn't working quite right, and you can provide an in-app setting to increase the tracing level to
Verbose of, say, the
MyApp.Commands.MyCommand source). This will cause the verbose messages for that particular command, to end up in the MyApp trace destination (i.e. the XML Activity Tracing-enabled listener)