Extensions: Move ILoggingBuilder to Microsoft.Extensions.Logging.Abstractions

[ericwj]

I don't want to depend on Microsoft.Extensions.Logging. Please move ILoggingBuilder to Microsoft.Extensions.Logging.Abstractions.

Is there a really good reason why it is in Microsoft.Extensions.Logging?

From where I stand, it is an abstraction.

[davidfowl]

We didn't want to make Logging.Abstractions pull in DI.Abstractions.

[ericwj]

OK I see. Don't recall I've much used them apart but sure that's reasonable.

[davidfowl]

I now think we should do this.

[ericwj]

Its just interfaces you'd pull in..

[pakrym]

@davidfowl DI is not required for logging implementation. But then you are required to reference our implementation to write provider implementation. Maybe referencing DI is less evil

[davidfowl]

Maybe referencing DI is less evil

@pakrym yep

[gulbanana]

I prefer the current situation. At my company we use Microsoft.Extensions.Logging without Microsoft.Extensions.DependencyInjection - our libraries use the logging abstractions, and when used with ASP.NET Core they can plug into its own loggerfactory. ILoggerBuilder is more specific to the asp.net/DI way of doing things, so it seems fine for it to be in the concrete package - or even in a higher-level package which composes together Logging and DependencyInjection.

[gulbanana]

we also have our own internal concrete ILoggerFactory etc - the current design means that this works really well, with consumers of our libraries able to use various providers without needing Microsoft.Extensions.Logging itself, only the abstractions, but capable of interoperating with asp.net or similar libs if they like

[davidfowl]

Yea but depending on DI.Abstractions adds nothing but a single dependency and the benefit is that providers don't need to reference the concrete implementation of the LoggerFactory to make extension methods.

[gulbanana]

it wouldn't be a huge deal but it's a bit annoying. why do they need to reference concrete MEL - are they adding extensions to ILoggingBuilder as well as ILoggerFactory?

[ericwj]

Could add Microsoft.Extensions.Logging.DependencyInjection.Abstractions - or the other way around - but that's on the path to the curse of dimensionality.

[pakrym]

@davidfowl do you still think we should pursue this?

[muratg]

@davidfowl I don't expect we'll do this. Reopen if you disagree.

[niemyjski]

This stinks... So I had extensions in our third party library for ILoggerFactory and now it's moved into this which makes me take a hard dependency or leave it and have the user have two different ways to configure the logging and my way might be broken in a future update.

e.g., [Obsolete("This method is obsolete and will be removed in a future version. The recommended alternative is AddConsole(this ILoggingBuilder builder).")].

[ahoefling]

@davidfowl @muratg

I am working on a large Open Source migration from .NET Framework to .NET Core for DNN (Formerly DotNetNuke). Earlier this year I leveraged the Dependency Injection libraries and configured it which set us up to re-write our logging code using the Logging.Abstractions project.

Currently I have a working implementation using only the Logging.Abstractions project, this uses a fork of log4net that we maintain. The platform is not ready to swap out the Logging implementation for the Microsoft Logging Project, but that will come when we are closer to the ASP.NET Core switch. This slow migration style is necessary to limit breaking changes in how logging is handled in the platform.

I was starting to convert our startup routines mimic behavior of the ASP.NET Core startup and utilize the ILoggerBuilder, when I realized the interface are not in the Logging.Abstractions NuGet. Moving this interface to the Logging.Abstraction project makes a lot of sense to me, and I am willing to make a PR if this is approved.

Questions

• Is there any chance we could get this interface moved over to the Logging.Abstractions project? I would be willing to submit a PR
• Is there another recommendation you may have?
• Should I just pull in the full Logging project even if I'm only using the ILoggingBuilder

[davidfowl]

Is there any chance we could get this interface moved over to the Logging.Abstractions project? I would be willing to submit a PR

Nope, I still don't think Logging.Abstractions should depend on IServiceCollection. We need to sort this out though. There's a bit of a layering issue introduced here since we added this. However, I don't think the answer is to move it.

Should I just pull in the full Logging project even if I'm only using the ILoggingBuilder

Seems reasonable to do so for this. Are you just wiring a logging provider?

[ahoefling]

Thanks for the quick response 👍

@davidfowl

Nope, I still don't think Logging.Abstractions should depend on IServiceCollection.

This does make sense, it is a tough problem to solve and I understand we don't want the Logging.Abstraction to take a dependency on the IServiceCollection

@davidfowl

Are you just wiring a logging provider?

Currently I built my own implementations of ILoggerFactory and ILoggerProvider if I pull in the full Logging NuGet I can remove my ILoggerFactory implementation and just take the one provided by the library.

Now that I have spoken with you and thought through this a little more I think this is going to be a much better approach for our long-term migration to .NET Core. This will allow the platform to utilize logging providers the exact same way using the LoggerFactory provided by this library.