title: Should I take ILogger, ILogger<T>, ILoggerFactory or ILoggerProvider for a library?
body: <p>This may be somewhat related to <a href="https://stackoverflow.com/q/46013762/91">Pass ILogger or ILoggerFactory to constructors in AspNet Core?</a>, however this is specifically about <strong>Library Design</strong>, not about how the actual application that uses those libraries implement its logging.</p>
  
  <p>I am writing a .net Standard 2.0 Library that will be installed via Nuget, and to allow people using that Library to get some debug info, I'm depending on <a href="https://www.nuget.org/packages/Microsoft.Extensions.Logging.Abstractions/" rel="noreferrer">Microsoft.Extensions.Logging.Abstractions</a> to allow a standardized Logger to be injected.</p>
  
  <p>However, I'm seeing multiple interfaces, and sample code on the web sometimes uses <code>ILoggerFactory</code> and creates a logger in the ctor of the class. There's also <code>ILoggerProvider</code> which looks like a read-only version of the Factory, but implementations may or may not implement both interfaces, so I'd have to pick. (Factory seems more common than Provider).</p>
  
  <p>Some code I've seen uses the non-generic <code>ILogger</code> interface and might even share one instance of the same logger, and some take an <code>ILogger&lt;T&gt;</code> in their ctor and expect the DI container to support open generic types or explicit registration of each and every <code>ILogger&lt;T&gt;</code> variation my library uses.</p>
  
  <p>Right now, I do think that <code>ILogger&lt;T&gt;</code> is the right approach, and maybe a ctor that doesn't take that argument and just passes a Null Logger instead. That way, if no logging is needed, none is used. However, some DI containers pick the largest ctor and thus would fail anyway.</p>
  
  <p>I'm curious of what I'm <em>supposed</em> to be doing here to create the least amount of headache for users, while still allowing proper logging support if desired.</p>