Closed Workshop2 closed 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....
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).
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).
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 (?)
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
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.
Is this intentional or a bug?
Many thanks, Simon