Home

Introduction

LibLog is designed specifically and primarily for library developers that want to provide logging capabilities.

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 dependency on your choice of logging framework. This causes issues when they 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 your 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 used by many libraries that don't want to do 1 or 2. LibLog is designed to help those that would 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. 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.

Diagnostic Contexts

LibLog also supports nested and mapped diagnostic contexts for all built-in providers except for Microsoft.Practices.EnterpriseLibrary.Logging.