Deprecating LibLog

[damianh]

All, I've been considering the future of LibLog and I think it's time for it to be wound up. I have not been a good maintainer recently and I'm starting to find myself using it less and less especially since .NET Core 2.0 which has made me reflect on it's role and purpose.

It originated from a time when, as a library developer, one wanted to easily to support logging and a variety of great logging solutions but avoid the versioning, assembling binding redirect and adaptor package hell that it would entail.

With .NET Core and the new SDK project formats, the occurances of assembly binding issues have been largly mitigated (but not eradicated) and, for better or worse, Microsoft has standardised the logging interface. It's clear that community contracts will never have traction and that only MS can bring such to the .NET ecosystem. The majority will use Microsoft.Exentions.Logging because it's there. Like it's Dependency Injection counterpart, it's a "conforming" interface and maintainers of logging libraries will need to conform to it to stay relavent. As such, I don't think this project has a role going forward. (If anyone has any arguments to counter that, now would be a good time to express them.)

The plan is to have things wound up around time .NET Core 3.1 lands. I will do a release soon which contains some recent fixes and improvements but I'm not really expecting to do any more after that. Issues will be closed off and the readme will be updated to point people towards Microsot.Extensions.Logging. Eventually the project will be archived and the nuget package will be marked deprecated.

Finally I would like to give a special shout out to everyone who submitted PRs and issues. In particular to @snakefoot - I am very grateful for your contributions and participation.

Cheers,

Damian

[snakefoot]

I think the decision makes sense. It will take some effort for all libraries to stop using LibLog. And not all libraries wants a dependency on Microsoft-Extension-Logging.

It will be a long transition period, but just like Common Logging has reached its final state, then I guess the time has also come for LibLog. But your statement gives a clear direction, instead of leaving existing users in an limbo of uncertainty.

Of course it is possible to create a LibLog-LoggingProvider that forwards LibLog-LogEvents to the MEL-LoggingFactory. If wanting to forward the LogEvents from an existing old library that uses LibLog into a new MEL-application.

It has been a pleasure helping out, and I have learned a lot from participating :)

[mniak]

Thanks for your service!

[damianh]

It indeed will be a long transition. LibLog will very likely continue to work for quite some time (it's been suprisingly reslient so far). And yes it's completely possible to add an adapter/provider to a library to forward to MEL. That was one of my very first design decisions - provide an escape hatch in case things stopped working for old(er) packages.

There have been a couple of schisms in the .NET space that has caused some upheavel for library/package maintainer over the years. .NET Standard and .Net Core being a recent one - there are lots of nuget packages still only targeting net40/net45 that are no longer usable / viable.

The next schism is .NET Core 3 which pulls in most of the rest of the ecosystem originally left behind with dotnet core (except WCF devs 😄 ). AspNetCore is now no longer shipped as nuget but as part of the entire SDK and, because of dependecy chains, Platform Extensions (Microsoft.Extensions.) is effectively shipped as part of the platform. MEL may as well be in the System. namespace now - it's going to be everywhere. I will assert that libaries that want to log and who don't adopt it will find themselves become less desirable to their consumers.

I did consider entirely aligning LibLog's public API aspect with MEL with the idea of some sort of auto wireup. But I have consider how I invest my limited time and I didn't feel this would get a good return.

[damianh]

It indeed will be a long transition. LibLog will very likely continue to work for quite some time (it's been suprisingly reslient so far). And yes it's completely possible to add an adapter/provider to a library to forward to MEL. That was one of my very first design decisions - provide an escape hatch in case things stopped working for old(er) packages.

There have been a couple of schisms in the .NET space that has caused some upheavel for library/package maintainer over the years. .NET Standard and .Net Core being a recent one - there are lots of nuget packages still only targeting net40/net45 that are no longer usable / viable.

The next schism is .NET Core 3 which pulls in most of the rest of the ecosystem originally left behind with dotnet core (except WCF devs 😄 ). AspNetCore is now no longer shipped as nuget but as part of the entire SDK and, because of dependecy chains, Platform Extensions (Microsoft.Extensions.) is effectively shipped as part of the platform. MEL may as be in the System. namespace now - it's going to be everywhere. I will assert that libaries that want to log and who don't adopt it will find themselves become less desirable to their consumers.

I did consider entirely aligning LibLog's public API aspect with MEL with the idea of some sort of auto wireup. But I have consider how I invest my limited time and I didn't feel this would get a good return.

[damianh]

Well .net core 3.1 landed today so wrapped things up:

• 5.0.8 final release on nuget.org
• closed all remaining issues and PRs
• updated the readme.

Final step is to hit the archive button.

Cheers folks.

(I can be reached on twitter https://twitter.com/randompunter)

[darkl]

Thanks for the good work!