Home

LibLog is designed specifically and primarily for library developers, who want to provide logging capability.

This has been typically achieved in one of three ways:

1. Take a hard dependency on a logging framework. Thus forcing all consumers of your library to also take a reference on your choice of logging framework. This causes issues when the want to use a different framework or are using a different version of the same one.
2. Use Common.Logging. Providing an abstraction over all the other frameworks has merit but it will add a reference to you consumers projects. It's still a versionable dependency and can be prone to versioning clashes with other libraries. Common.Logging's ILog contains ~65 members whereas LibLog's ILog has just single method making it easier to implement custom loggers.
3. Define your own Logging abstraction. A common approach by many libraries who don't want to do 1 or 2. LibLog is designed to help those that who otherwise go down this path.

Transparent Logging support

When using this in various libraries, I got fed up re-implementing / copy-pasting providers. So included in LibLog is transparent, reflection based support, for several loggers: SerilogProvider, NLogProvider, Log4NetProvider, EntLibLogProvider, LoupeLogProvider, ColourConsoleLogger. This is pure 🍰 This means that if a user simply references one of the logging frameworks, your library should automatically log to that. There is a search order (see LogProviderResolvers) so if there are multiple frameworks referenced in end application, this may be a gotcha.

Even though the APIs of the various loggers have been very stable over time, if they do change your library will fail gracefully. If (when!) that happens, users of your library can call LogProvider.SetCurrentLogProvider() to get things working again.