net-commons / common-logging

A portable logging abstraction for .NET
http://net-commons.github.io/common-logging
Apache License 2.0
649 stars 205 forks source link

ConsoleOutLogger missing in 3.4.0 for .NET Standard #151

Closed Workshop2 closed 7 years ago

Workshop2 commented 7 years ago

Is this intentional or a bug?

Many thanks, Simon

sbohlen commented 7 years ago

@Workshop2

I think its technically both a bug and a feature (for the time being, at least) :P

Here's my (somewhat ugly) analysis of what I think is going on here....

  1. We don't presently support .NET Standard in 3.4.x. Now that 3.4.1 has been released to GA, work is currently underway to introduce formal support for (various) .NET Standard targets in 4.0 (as outlined in https://github.com/net-commons/common-logging/issues/148).

  2. I've tested your scenario (e.g., running install-package common.logging from the package manager console against a netstandard1.3 class lib project) and surprisingly (to me, at least!) I do indeed get some version of Common.Logging installed despite the fact that there are currently no packages published to NuGet that declare support for any netstandard target(s).

  3. Since we don't (yet) provide packages with an explicit declared support for netstandard1.3, what I believe NuGet is doing here is 'reverse-engineering' the definition of netstandard1.3 and 'discovering' that there seems to be a package for Common.Logging that also targets all the runtimes that are included in the definition of netstandard1.3. Its this package that is being installed in this scenario. I have no inside information, but I assume that this behavior was introduced in order to ease the transition to netstandard for anyone consuming NuGet packages -- this way, people don't try to move to netstandard only to discover that there are ZERO packages in NuGet for them to depend upon (?)

  4. It turns out that the reason you're not getting ConsoleLogger under netstandard1.3 is that the Common.Logging packages NuGet is selecting for you don't formally target netstandard1.3 but instead target a collection of runtimes where there is no support for System.Console (e.g., Windows Phone, Windows UWP) and so ConsoleLogger can't be included there. This is why the binary you're getting in this scenario contains only NoOpLogger and DebugLogger (the two guaranteed to be supported everywhere .NET runs, and we could safely include them in the common.logging.dll binary you're getting installed by NuGet in this context).

FWIW, this problem will be resolved with the initial release of Common.Logging 4.0 where we will both introduce explicit support for netstandard targets and refactor all 'built-in' loggers (e.g., NoOpLogger, DebugLogger, ConsoleLogger) into their own separate packages/assemblies rather than including them in the 'main' common.logging.dll as discussed in https://github.com/net-commons/common-logging/issues/120 precisely to mitigate exactly the problem/issue you're raising here.

Hope this helps clarify. Sorry for the length of this, but I wanted to ensure that we documented this behavior in some detail for the benefit of others who may also run into this before we're able to release 4.0 to address this mess :P

Workshop2 commented 7 years ago

Thanks for the information. I was confused to see it working in dot net core only to see an issue relating to it not yet being compatible.

I look forward to seeing what happens next.