How to use log4net with Dependency Injection

Question

I'm trying to figure out what the right patter and usage of log4net is with a dependency injection framework.

Log4Net uses the ILog interface but requires me to call

LogManager.GetLogger(Reflection.MethodBase.GetCurrentMethod().DeclaringType)

in each class or method where I need to log information. This seems to go against IoC principles and couples me to using Log4Net.

Should I somehow put in another layer of abstraction somewhere?

Also, I need to log custom properties like the current user name like this:

log4net.ThreadContext.Properties["userName"] = ApplicationCache.CurrentUserName;

How can I encapsulate this so that I don't have to remember to do it everytime and still maintain the current method that is logging. should I do something like this or am I totally missing the mark?

public static class Logger
{
    public static void LogException(Type declaringType, string message, Exception ex)
    {
        log4net.ThreadContext.Properties["userName"] = ApplicationCache.CurrentUserName;
        ILog log = LogManager.GetLogger(declaringType);
        log.Error(message, ex);
    }
}

Answer 1

How I did it was to create my own interface, and had a class implement that interface that used Log4Net, and injected that class. In that way you are not tied to Log4Net...you can just create another class for a new logger and inject that class.

Answer 2

I think you're not seeing the forest for the trees here. ILog and LogManager are a lightweight façade almost 1:1 equivalent to Apache commons-logging, and do not actually couple your code to the remainder of log4net.

<rant>
I've also found that almost always when someone creates a MyCompanyLogger wrapper around log4net they miss the point badly and will either lose important and useful capabilities of the framework, throw away useful information, lose the performance gains possible using even the simplified ILog interface, or all of the above. In other words, wrapping log4net to avoid coupling to it is an anti-pattern.
</rant>

If you feel the need to inject it, make your logger instance accessible via a property to enable injection but create a default instance the old-fashioned way.

As for including contextual state in every log message, you need to add a global property whose ToString() resolves to what you're looking for. As an example, for the current heap size:

public class TotalMemoryProperty
{
 public override string ToString()
 {
  return GC.GetTotalMemory(false).ToString();
 }
}

Then to plug it in during startup:

GlobalContext.Properties["TotalMemory"] = new TotalMemoryProperty();

Answer 3

If you are really concerned about having multiple loggers, you can always declare a global logger and call that for all your logging needs. The downside to this is that you lose the built in ability to identify the class that the log was issued from, but you can also inject your own custom message into the log to identify the class.

It depends on how robust you want the logging to be. You can also simply put the logger at the main class and let all unhandled exceptions bubble up to it for logging.