NuGet - Common.Logging.NLog31 incompatible with PCL

[eropple]

I'm trying to use Common.Logging.Portable (as my core library is PCL), but it appears that Common.Logging.NLog31 doesn't play nicely with C.L.Portable. It wants to have Common.Logging; obviously, having both C.L and C.L.Portable in the same project is Not Fun.

Any help would be appreciated!

[sbohlen]

The reason this doesn't work is that Common.Logging.NLog31 has a dependency on Common.Logging (which is itself not PCL-compliant). As you're discovering, you can't just swap out Common.Logging with Common.Logging.Portable as they aren't 100% interchangeable. There are things (e.g., [Serializable] ) not supported in Common.Logging.Portable that are expected by Common.Logging.NLog##.

Can you validate that NLog itself is PCL-compliant? Per this open issue NLog/NLog#155 it seems to me from my quick read that NLog isn't PCL-compliant (and so wouldn't be able to be referenced by your PCL assembly anyway, even if you were able to reference Common.Logging.NLog31.

Is there a PCL variant of NLog? If so, we'd likely want/need to create an e.g., Common.Logging.NLog31.Portable package to properly support it. Otherwise, you're right that you can't use Common.Logging.NLog31 atop Common.Logging.Portable.

Can you advise if we're reading the state of PCL support in NLog incorrectly --? We're happy to spin up support for a PCL-compliant NLog instance (or any other logging framework, for that matter), but I don't think that there is one as of now (unless we've overlooked it).

Thanks,

-Steve B.

-----Original Message-----
From: "Ed Ropple" notifications@github.com
Sent: ‎11/‎3/‎2014 1:43 PM
To: "net-commons/common-logging" common-logging@noreply.github.com
Subject: [common-logging] NuGet - Common.Logging.NLog31 incompatible with PCL(#67)

I'm trying to use Common.Logging.Portable (as my core library is PCL), but it appears that Common.Logging.NLog31 doesn't play nicely with C.L.Portable. It wants to have Common.Logging; obviously, having both C.L and C.L.Portable in the same project is Not Fun.
Any help would be appreciated!
—
Reply to this email directly or view it on GitHub.=

[eropple]

Perhaps I'm misunderstanding, but neither NLog nor C.L.NLog31 need to be PCL themselves to reference C.L.Portable, correct? Otherwise, I'm not seeing the point of C.L.Portable at all--if your PCL libraries can't interact with a platform-specific logger, that seems to defeat the entire purpose of it.

My PCL library doesn't need to link against a logging implementation at all. It needs to consume LogManager, whose Adapter is set by platform-specific code in a separate assembly. Make sense?

[sbohlen]

Ah, sorry, I misunderstood your use-case.

Based on the (entirely valid!) issues you raise here, it points out that the strategy we shifted to for PCL support in 2.3.x is fundamentally wrong and needs to be largely re-thought :(

The original approach to PCL support (in this PR #30) introduced a new assembly, Common.Logging.Core, which targeted PCL. Common.Logging (and the other upper-level abstractions) then each took a dependency on Common.Logging.Core and the types defined in Common.Logging.Core properly 'flowed' to the upper-level assemblies (in support of your scenario).

The trouble with this approach was that it fundamentally broke the guarantees of semantic versioning in some troubling ways. The most egregious of these was that since there's no support for [Serializable] in PCLs (and the Common.Logging.Core PCL was common across all of Common.Logging), all of Common.Logging suddenly lost its ability to be serialized. This meant that any object of your own that retained a reference to a logger also lost the ability to be serialized. This (as you can imagine) broke a lot of existing consumers of Common.Logging :(

Because of this , in Common.Logging 2.3.x, we switched to a different strategy for providing PCL support: we produced a Common.Logging.Portable assembly that targeted PCL but was completely outside the assembly-dependency hierarchy for the rest of Common.Logging (i.e., unlike Common.Logging.Core where it was the low-level ass'y upon which the rest of Common.Logging took a dependency, Common.Logging.Portable wasn't taken as a dependency by any of the rest of Common.Logging in the 2.3.x release).

This completely solved the breaking-changes issues (e.g., Common.Logging recovered its ability to be marked [Serializable], etc.), but as you quite correctly identify, it also completely breaks the (entirely valid) scenario you're trying to achieve because the PCL-compliant types in Common.Logging.Portable are similar but not the same as the types in the rest of Common.Logging (and the C# compiler doesn't come with a good-enough-types-match=ON switch).

Beginning this coming weekend, its my intent to take a completely fresh look at the world of PCL support in Common.Logging to see if there's perhaps a third approach that can be implemented to both address the issues like support for [Serializable] and the (no-doubt very common) use-case that you're outlining here.

Right now, before really giving it significant deep thought and exploration/validation effort, I'm leaning towards (perhaps) a strategy where we return to the idea of Common.Logging.Core being the 'root' of the assembly dependency hierarchy, but that Common.Logging.Core might only contain all of the interfaces, and no implementations at all. This would free up Common.Logging implementations to be tailored more carefully to the capabilities of the platforms, rather than having to accept them as being hampered by the capabilities of the lowest-common-denominator platform that the PCL ass'y is targeting.

Because there's no way around the fact that this will introduce (again) breaking changes, this effort won't see the light of day until Common.Logging 3.0, but TBH that's probably not all that far away as its our intent to fold in the pending PR that we know would introduce breaking changes (#56), resolve a few other issues along the way, and then move as speedily as possible to a 3.0 GA (probably mid-DEC if all goes according to loose plans).

Sorry for the length of this, but I wanted to document it all in one place and I hope it helps clarify how we got into this quandary a little better.

[eropple]

Just got back around to this. Happy to see that I'm not completely crazy. :) I ended up putting a translation layer in my DI container -- I'm using it for a game, so having a DI container is kind of wacky, but roll with it -- that just wraps ILog with a suspiciously similar interface, so my PCL stuff is happy, but I look forward to seeing what y'all come up with!

[sbohlen]

Great -- happy to hear it. Closing this as its superseded by #71