Move away from `Common.Logging` library

feature
1

Common.Logging.Core is deprecated and Common.Logging.Portable is added.Do we need to get a updated release with the new Dependency.

https://www.nuget.org/packages/Common.Logging.Core/

2

Argh, I can’t keep pace with Common.Logging changes. Such a common thing should be more stable. Thank you for keeping me in touch with new changes. I want to implement in 2.0 a simple logging interface to achieve the following goals:

  • Support out of box popular logging frameworks without need to install additional packages (through relection).
  • Users should be able to provide own implementation to hook with the current logger they use in project.

This implementation can be considered as a proof of concept. What do you think?

2 Likes
3

Maybe it’s wise to also list the dependency to a maximum (or fixed) version of Common.Logging in NuGet.

See http://docs.nuget.org/docs/Reference/Versioning

(For me the deployment to our test environment just broke because of this dependency, somehow it did not break on my development machine)

4

Yep, but this will break current users. Do you have issues with previous version of the Common.Logging package?

5

My project also broke after updating Common.Logging, because it failed to find Common.Logging.Core (which is automatically removed when updating Common.Logging to 2.3.1). The workaround for me was to manually re-add Common.Logging.Core, but this feels wrong as it is deprecated. If Hangfire were updated to use the latest Common.Logging version, this would probably work as expected?

6

Please use LibLog and let the enduser specify the logging implementation.

LibLog is essentially a single cs file with multiple provider for Nlog, Log4Net, EntLib, Serilog and Loupe, and it is easy to create your custom logprovider

see:

edit:

that’s also liblog…

1 Like
7

@rikbosch thank you, you saved my day!

This is a nice situation. Initial thought was to remove the need to upgrade current project dependencies to latest versions to use Hangfire. This decision works perfectly with Newtonsoft.Json package, but failed for Common.Logging. So, some action required for logging subsystem in Hangfire.

Continue to use Common.Logging 2.2.0

This seem as a reasonable solution unless some other package you use in your application depends on the latest version. In that case you will be unable to use Hangfire, so it is unacceptable to continue to use the old version.

Upgrade Common.Logging to the latest version

This step will require additional actions for Hangfire users as they need to update some other packages (for example, Common.Logging.NLog) in order to use the latest package version. The trouble is that other Hangfire packages (Hangfire.PostgreSql) depend on the old version of Common.Logging package, and they should be re-released.

After upgrading, we may have the same problems in future.

Change Hangfire to use LibLog

A single file for you to either copy/paste or install via nuget, into your library/framework/application to enable dependency free logging. It contains transparent built-in support for NLog, Log4Net, EntLib Logging, Serilog and Loupe or allows the user to define a custom provider.
– LibLog readme

So, if you use one of the logging library mentioned above, you don’t need to install anything else, it just works. If you have other logging provider, all you need is to implement two simple interfaces:

public interface ILogProvider
{
    ILog GetLogger(string name);
}

public interface ILog
{
    bool Log(LogLevel logLevel, Func<string> messageFunc);
    void Log<TException>(LogLevel logLevel, Func<string> messageFunc, TException exception) where TException : Exception;
}

This step will require to do the following things:

  • Replace all references to Common.Logging API with the new logging provider in all Hangfire projects using Common.Logging.
  • Implement interfaces described above for target projects if required, or at least remove the LogManager.Adapter = /* ... */ line in the project.

Actions described above are similar to actions required to do after upgrading the Common.Logging version to the latest one, so it seems reasonable to me to perform the switch to the LibLog as soon as possible.

8