Use LoggerFactory instead of LoggerProvider

[304NotModified]

current pro and cons:

pro

• faster (less overhead)
• MEL-Filtering ignored (less confusion for some)

con:

• AddConsole and other MS stuff not working - see UseNLog() in 4.5.0-beta01 removes ConsoleLogger from .Net Core #199
• Init config of AddConsole etc ignored
• MEL-Filtering ignored (more confusion for some)

[304NotModified]

also related: NLog/NLog.Extensions.Logging#202

[alexandrejobin]

pros

• you only have one configuration file to configure everything instead of two
• a lot less confusion

cons

• you have to choose between Microsoft Logger framework and NLog because you can't use both but since that nlog already have targets for Console et Debug, you don't really lose any feature

My opinion is that if you want to register a new provider in the LoggerProvider, you must fully follow the way it work. It must be driven only by the Logger configuration.

Since that nlog is not a real provider for the Logger but a full logging framework, I think it make sens that nlog should take full control of the logging system. Why choose AddConsole and AddDebug when nlog already have targets for them?

[304NotModified]

Thanks! I think you're right. It would be nice if we could support both (referring to you have to choose between Microsoft Logger framework and NLog because you can't use both ).

This is a breaking change, thus I think it should be V5 if applied

[alexandrejobin]

When you call UseNLog, maybe we can pass a parameter to tell if you want to use it as a full framework or a provider for Logger?

[304NotModified]

that's an option, but maybe also confusing if we have 2 modes.

[alexandrejobin]

So what are you suggesting? You've said that you wanted to support both :)

[snakefoot]

The NLogLoggerFactory was created with NLog/NLog.Extensions.Logging#135 and works just fine. Though not sure how to ensure NLogLoggerFactory is used at startup :)

See also aspnet/Logging#420

[nblumhardt]

We've had some experience taking the ILoggerFactory route with Serilog this last year or so. Your pros/cons are pretty close to the mark.

The user experience has worked out well in most respects, there's minimal semi-compatible gunk to work around, and no perf/complexity penalty to suffer choosing Serilog (via the factory) vs. the compromises we'd be stuck with if we'd stayed on the provider track. I'd definitely take this route again, if we were to face the decision a second time.

There are a few places where there are gaps, but hopefully these will close over time if plugging in at the factory level becomes more commonplace. If you need any details of how things have come out for Serilog please drop us a line! :-)