Inject ILogger in a service.

[DibranMulder]

Is it somehow possible to inject the ILogger into the constructor of a Service? I rather not pass on the instance, especially not when I have a multi layer (service / repository) pattern.

[ryanspletzer]

Please yes.

[kemmis]

+1

Does it work if we accept an ILoggerFactory in the constructors instead?

[ryanspletzer]

It looks like it will pass in an ILoggerFactory actually!

However in order to get the created logger to output to the functions host I had to adjust the category name to look like Function.<FunctionName>.User -- I found this category name by inspecting the ILogger that's provided in the function method:

I'm guessing that the reason an ILogger is passed along today is because it retains the category name of the Function and the console / function host will only output logs for that function from the associated category... Which makes it a challenge if you are injecting a singleton service in multiple functions that you all want to have logs output from.

[ryanspletzer]

Ok I found Microsoft.Azure.WebJobs.Logging.LogCategories one of which I tested Microsoft.Azure.WebJobs.Logging.LogCategories.Singleton which is the string "Host.Singleton" -- this string is independent of what function execution you're in and will output logs to the function host.

It would be nice to register one of these up front in Startup.cs so ILogger could just be injected everywhere vs. calling CreateLogger on the loggerFactory, but I suppose that the factory controls logger instance lifetime and would hope that a new ILogger is not being created everywhere for each call to the factory CreateLogger method. The instance likely just gets created once for the first call and then kept around for the lifetime of the running of the function host.

[ryanspletzer]

More info in comments in the code on LogCategories here:

https://github.com/Azure/azure-webjobs-sdk/blob/b798412ad74ba97cf2d85487ae8479f277bdd85c/src/Microsoft.Azure.WebJobs.Host/Loggers/Logger/Constants/LogCategories.cs

[ryanspletzer]

I think Host.Singleton is more to do with the singleton attribute which appears to be related to durable functions.

https://docs.microsoft.com/en-us/azure/app-service/webjobs-sdk-how-to#singleton-attribute.

For now I've decided switched to this below, with a category that I create based on function name when I'm in the scope of a function itself (to be in line with the ILogger that was passed into the function method before), and another "Function.DependencyInjection.User" constructed category (or whatever arbitrary inner string you want) for creating ILogger's in services created through DI. It's probably not perfect / ideal but works for now until we have an "official" approach for this.

Prior to official release of this DI extension when I had made my own DI extension binding based on various write-ups in the community, I was intercepting the service collection in the IExtensionConfigProvider and creating/registering a "DependencyInjection" category ILogger at that point from the logger factory which was available to services, and that was working just fine up to now, so this approach isn't too different from that, and finally lets me get off my own DI binding and onto the new one provided by Microsoft. :)

[brettsam]

Use ILogger<T> and you should get your logger injected. You'll need to explicitly allow your category (the full -- or even partial -- type name of T) through the filter due to: Azure/azure-functions-host#4345

ILogger itself isn't supported (by default) in .NET Core DI.

Some updated comments/links with more details here: Azure/azure-functions-host#2720 (comment)

[fabiocav]

Closing this as the comment above addresses the issue.

[ryanspletzer]

Thank you for the guidance @brettsam!