ILogger Dependency Injection for Libraries
The below is what I came up with to inject a logger into a library, but something feels off. Can anyone advise if something in my approach needs tweaking?
17 Replies
I don't see an obvious issue. I mean, I would use things like an enum instead of a string to determine the type, but of course this just seems to be a throw-away example so...
Yep, in my actual code I am using an enum but didn’t bother for the example. What I ideally wanted was to be able to show a context of FooFactory within FooFactory, FooRed within FooRed, and FooBlue within FooBlue, but since the only entry point to the class would be the factory, I couldn’t figure out how to do that. The below fails, understandably, so I wasn’t sure if libraries were just supposed to expose one “context”:
All of my library code just takes an ILogger. I don't think the library code should care if it's an ILogger<T> behind the scenes...what is the library code supposed to do with that?
Just ILogger reduces coupling to other types, which is usually what you want.
Interesting! Do you happen to have any public examples of that? Been trying to find actual usage of ILogger in libraries, since I learn best from concrete rather than contrived examples.
Most of my stuff is all internal, but just do something like grep the Roslyn source code for ILogger and you'll see it's usually just a plain ILogger that's passed in to library code. At least from a quick look it seems that way.
Unknown User•10mo ago
Message Not Public
Sign In & Join Server To View
Do you have an example of what you mean? I am using the Msft.Ext.Logging ILogger interface in my example above already so that I’m not tied to Serilog. Is there a different area I would need to change as well?
Unknown User•10mo ago
Message Not Public
Sign In & Join Server To View
@TeBeCo I don't understand this example at all.
Unknown User•10mo ago
Message Not Public
Sign In & Join Server To View
@TeBeCo this code will be in a library with the only point of entry being FooFactory, so I would not be able to register FooRed or FooBlue. In that case are you saying I would want to inject a factory all the way down like this?
It seems the recommendation for library code is to indeed take an ILoggerFactory, at least for general purpose public facing libraries.
Logging guidance for .NET library authors - .NET
Learn how to expose logging as a library author in .NET. Follow the guidance to ensure your library is correctly exposed to consumers.
If the logger is not passed along to other classes, the recommendation is to use ILogger<T> where T is the type name.
Apparently my practice of just acceping ILogger (non-generic) is not considered a best practice.
Unknown User•10mo ago
Message Not Public
Sign In & Join Server To View
@TeBeCo, I like that a lot, it’s very clean. For internal classes which are only instantiated inside the library and not available to callers, would the best practice be for those to take the non-generic
ILogger
and have whichever class instantiates them pass in its own logger, since its type is meant to truly be internal and shouldn’t be leaking its context into logs anyhow?
e.g.,
Unknown User•10mo ago
Message Not Public
Sign In & Join Server To View