Passing in the type of the declaring class for NLog using Autofac

Question

Following on from this question I would like autofac to inject the type of the declaring object into the constructor of my NLog service, so that it can correctly log which t

Answer 1

The following technique works well in our experience:

1. Create an attribute like below, which can be applied at class level or at the injection site:

   [AttributeUsage(AttributeTargets.Parameter | AttributeTargets.Class)]
   public class LoggerAttribute : Attribute
   {
       public readonly string Name;
   
       public LoggerAttribute(string name)
       {
           Name = name;
       }
   }
   

2. Create an Autofac module that you register with the ContainerBuilder:
   

   public class LogInjectionModule : Module
   {
       protected override void AttachToComponentRegistration(IComponentRegistry registry, IComponentRegistration registration)
       {
           registration.Preparing += OnComponentPreparing;
       }
   
       static void OnComponentPreparing(object sender, PreparingEventArgs e)
       {
           var typePreparing = e.Component.Activator.LimitType;
   
           // By default, the name supplied to the logging instance is the name of the type in which it is being injected into.
           string loggerName = typePreparing.FullName;
   
           //If there is a class-level logger attribute, then promote its supplied name value instead as the logger name to use.
           var loggerAttribute = (LoggerAttribute)typePreparing.GetCustomAttributes(typeof(LoggerAttribute), true).FirstOrDefault();
           if (loggerAttribute != null)
           {
               loggerName = loggerAttribute.Name;
           }
   
           e.Parameters = e.Parameters.Union(new Parameter[]
           {
               new ResolvedParameter(
                   (p, i) => p.ParameterType == typeof (Logger),
                   (p, i) =>
                   {
                       // If the parameter being injected has its own logger attribute, then promote its name value instead as the logger name to use.
                       loggerAttribute = (LoggerAttribute)
                       p.GetCustomAttributes(typeof(LoggerAttribute),true).FirstOrDefault();
                       if (loggerAttribute != null)
                       {
                           loggerName = loggerAttribute.Name;
                       }
   
                       // Return a new Logger instance for injection, parameterised with the most appropriate name which we have determined above.
                       return LogManager.GetLogger(loggerName);
                   }),
   
               // Always make an unamed instance of Logger available for use in delegate-based registration e.g.: Register((c,p) => new Foo(p.TypedAs<Logger>())
               new TypedParameter(typeof(Logger), LogManager.GetLogger(loggerName))
           });
       }
   }
   

3. You can now inject a named Logger in any one of these ways depending on individual scenarios:

   • By default, the injected logger name will be given the full type name of the class it is injected into:

     public class Foo
     {
         public Foo(Logger logger)
         {
         }
     }
     

   • Use a constructor parameter [Logger] attribute to override the logger name:

     public class Foo
     {
         public Foo([Logger("Meaningful Name")]Logger logger)
         {
         }
     }
     

   • Use a class-level [Logger] attribute to set the same logger name override for all constructor overloads:

     [Logger("Meaningful Name")]
     public class Foo
     {
         public Foo(Logger logger, int something)
         {
         }
     
         public Foo(Logger logger, int something, DateTime somethingElse)
         {
         }
     }
     

   • Use constructor parameter [Logger] attributes on each constructor overload to set different logger names depending on the context of how you were constructed:

     public class Foo
     {
         public Foo(Logger("Meaningful Name")]Logger logger, int something)
         {
         }
     
         public Foo(Logger("Different Name")]Logger logger, int something, DateTime somethingElse)
         {
         }
     }
     

     
     

IMPORTANT NOTE: If you register types to be resolved with logger constructor injection using Autofac's delegate registration, you MUST use the two parameter overload like so: Register((c,p) => new Foo(p.TypedAs<Logger>()).

Hope this helps!

Answer 2

Could make your NLogService generic, i.e. NLogService<T> and use Autofac's open generics support?

Then you could do this:

public class NLogService<T> : ILogger<T>
{
    private readonly Logger _logger;
    public NLogService()
    {
        _logger = LogManager.GetLogger(typeof(T).FullName);
    }
}

Answer 3

There is no real good way to do this with Autofac, because does not have support for 'context based injection' (which is what you are trying to do). There is a workaround, but it aint pretty...

What you can do is revert to property injection and define a base class or interface for that ILogService property. For instance, you can define the following interface:

public interface ILoggerContainer
{
    public ILogService Logger { get; set; }
}

Now you can implement this interface on all types that need a logger:

public class Consumer : IConsumer, ILoggerContainer
{
    public ILogService Logger { get; set; }
}

With this in place you can configure Autofac as follows:

builder.RegisterType<ILoggerContainer>()
    .OnActivating(e =>
{
    var type = typeof(LogService<>)
        .MakeGenericType(e.Instance.GetType());
    e.Instance.Logger = e.Context.Resolve(type);
});

Another workaround, that you may find cleaner is to inject an ILogger<T> with the same type as the type of the parent type:

public class Consumer : IConsumer
{
    public Consumer(ILogger<Consumer> logger) { }
}

This makes the configuration much easier and prevents you from having to have a base class. Which one is most appropriate is up to you.

As I said, these are workarounds, but to be honest, you might need to reconsider your logging strategy in your application. Perhaps you are logging at too many places. In the applications I write there is hardly ever a need to log, and when I do, I write an logging message that is expressive enough so that there is no need to communicate the type that triggered the event. And when you log exception, you will always have a complete stack trace (and exception logging should almost only happen in the outer layer of your application and not within services anyway).