PROPOSAL: Introduce .NET Standard support in Common.Logging 4.0 and sunset Common.Logging 3.x after 3.4

[sbohlen]

The project team would like to solicit comments/input from the community on the following proposal.

With all the churn in the .NET stack over the past few years, (e.g., PCLs, .NET Framework Profiles, WinRT, .NET Core, .NET Standard), its been challenging to keep projects like Common.Logging entirely aligned with what's needed for its adopters within all of the differing flavors of .NET.

Since the original concept of .NET Standard was first suggested (and along with it a completely different model/architecture for mutli-targeting class libraries), we've struggled for some time to arrive at a go-forward strategy for Common.Logging that would be aligned with the future direction/architecture of the .NET platform vs. being (mostly) backward-facing and constrained by legacy design decisions being carried forward from years prior. Part of the delay in our plans to support .NET Standard had been the gap between the arrival of .NET Standard and the availability of proper tooling/Visual Studio support for the concepts it represents.

Now that we've reached a point where the tooling is able to properly support the concepts, we think we've arrived at a go-forward strategy for this aspect of the project. After review and consideration we're now leaning strongly towards the following approach to support .NET Standard in Common.Logging:

1. Common.Logging 3.4 will be the last release of the 3.x version branch (e.g., there will be no 3.5 release planned and we will only do 3.4.x bug-fix releases as needed for some limited time).
2. Common.Logging 3.4 will be the last release of Common.Logging to support the 'legacy' .NET Framework versions which fall below the floor established by .NET Standard 1.0 (e.g., < .NET 4.5).
3. Common.Logging 4.0 will support only .NET Standard, leveraging the new multi-targeting capabilities introduced in Visual Studio 2017 and abandoning PCL support entirely. NOTE: given the differing availability of .NET APIs in each version of .NET Standard, we have not yet determined for certain the min. version of .NET Standard that will be supported by Common.Logging 4.0. But it will at least target >= .NET Standard 1.0 and will not support any .NET Framework version that falls outside the scope of .NET Standard as defined here.
4. Common.Logging 4.0 will support only Visual Studio 2017 as an IDE for building and contributing to the project. Support for building the project in legacy versions of Visual Studio will be dropped as they cannot support .NET Standard and the Community Version of Visual Studio 2017 is 100% free of charge and should be able to be used by adopters, contributors, etc. who desire to interact with the source code for the project.

Given that most versions of the .NET Framework < .NET Standard 1.0 have already reached (or are about to) their effective end-of-life re: support from Microsoft, this above approach seems a reasonable decision to make at this time. That said, since this decision will effectively 'orphan' any users of Common.Logging that are still targeting < .NET 4.5 from having access to any new features and/or new loggers for which support were to be introduced, we wanted to offer this opportunity for users to offer comment/feedback before this approach is officially pursued.

Thanks in advance for any and all input!

-The Common.Logging project team

[LHCGreg]

That all sounds reasonable to me, but would it be feasible to multitarget both netstandard and .NET Framework for those poor souls still on a version lower than 4.5? Would it require any extra work? I don't have any personal stake in it, just wondering.

[sbohlen]

I think I'd say that we can explore that and try to determine the LOE required to support that. If it can be achieved with a reasonable effort, I'd say we should try to accommodate as best we can.

I think in general the objectives go like this:

1. Consolidate support for multiple versions of Visual Studio into only Visual Studio 2017.
2. Remove support for versions of .NET not supported by reasonably recent versions of logging frameworks supported by Common.Logging (if e.g., Log4Net hasn't supported .NET 2.0 for 5+ years, why are we still supporting .NET 2.0 with Common.Logging?)

If we can achieve the above with adding support for e.g., .NET 3.5 then I think we're interested in going there; and if not, then not :)

[earloc]

Hi! Even though I am not using this lib atm, going in this direction definitely seems the way to go. I am for my self in the process of updating/restructuring some of my packages.
However, supporting legacy (full)-Frameworks with netstandard-tooling seems to be less painful as it ought to be with PCLs.
Just wanted to provide one or two maybe helpful links ;)

And for the matter of the lost souls still sticking with eg. .net2.0:
If the community keeps alive those frameworks by still supporting them in libraries like this one, even though MS as already EOLed those frameworks, many people do not see any reason to make the framework shift in the first place (or maybe having a hard time to convince other "stakeholders" or teammembers to perform an update). That said, dropping support for this kind of legacy may help others argumenting to do an update, as more and more packages will drop legacy-support, rendering these older frameworks more and more useless in regards of available (up-to-date) 3rd party solutions.

[sbohlen]

@earloc Thanks for the input (and the links). I'd not seen the second of those, but was aware of the process outlined there (agree w/ the author that its scattered all over the place and its helpful to have it all in one place).

As mentioned, we're not surrendering on supporting older/legacy versions of .NET Framework where the effort is considered somewhat minimal. But we are shifting our approach with an eventual 4.0 release to place less of an emphasis on continuing to support older versions of the framework to ensure continued compatibility and more of an emphasis on simplifying the complexity that supporting so many parallel versions of the framework has created for this project.

Your point that multi-targeting in VS 2017/net-standard is already much simplified from the PCL approach is well-taken, however. It may well be that after a grand refactoring of the solution to rely upon this new approach, we discover that its "just as easy" to continue to support older framework versions.

That said, there are a number of pending ISSUES/suggestions for changes to Common.Logging 3.x that have been postponed to 4.0 because they would represent breaking changes (and SemVer precludes us from implementing them until we rev the major version number). We're thinking that since 4.0 will already be breaking changes, this is also the time to make any necessary 'clean breaks' with the past legacy supported frameworks as well.

Thanks again for your feedback/input; more perspectives are definitely better than fewer!

[marcselis]

Will the new .NET Standard version be compatible with previous versions?
I mean, will code that uses common.logging for logging still compile after upgrading the nuget package to the new 4.0 version?
Most importantly this code:
private static readonly ILog _log = LogManager.GetLogger<MyClass>();