I’m still just a little new overall to the framework, but I’ve moved a light speed through a universe ! I have luckily avoided most pitfalls, but I have encountered seemingly most of them … and Logging is somewhat of a potential pitfall.
LibLog is excellent! And I have recently begun looking at potentially using that. But, I took a different approach with a similar concept … and would love to hear any input on this topic.
Developing a commercial solution, I have 40+ “internal” libraries implementing modularized features; and I took an approach to solve this by:
- Libraries don’t use “Loggers”, but instead use
- I have my own static central source from which libraries fetch
- This lives in my own small
TraceSource instances are just weakly held in a static dictionary, but always fetched there, so it enables instrumentation.)
Therefore, I have implemented central simple configuration: you can put a custom
ConfigurationSection in any config file, and use all the standard
Diagnostics configurations. My assemblies typically get a single
TraceSource instance per assembly, and you could instrument any one, but you can also simply set a global
TraceListener there as well, which is added to all
TraceSource instances (dynamically). In fact, they do no default configuration themselves (aside from in fact removing the default listeners in release) — and you just configure them in the standard way in the Diagnostics config.
So you can write a simple
TraceListener adapter that will pipe all of these
TraceSources to your desired logging sink.
The libraries now know nothing about “Loggers” and just trace with the core library diagnostics; and you can just instrument that.
Any comments; or further input is appreciated; and would be helpful to me!