.NET 5 upgrade

[clegendre]

Hi CK team!

Do you plan to upgrade this repository to .NET5 and the others depending on it (CK-AspNet-Auth, etc.)?
Will you accept PR if it is not a priority for you?

Thanks you !

Cédric

[olivier-spinelli]

Yo!
Yes we do. Since the very last 2020 version of CKSetup, the CKSetup.Runner can now handle net461, netcoreapp2.1, netcoreapp3.1 and net5.0. The Store (https://cksetup.invenietis.net) has been upgraded to handle net5.0 TFM. Now our goal is to settle a stable strategy in terms of LTS. And this is not as simple as it seems :).

We think that we should follow the lifetime policy of the .Net Core itself with a focus on the LTS versions. We'd like to provide LTS version of the CK stack in sync with .Net: currently netcoreapp3.1 and net5.0 should be available and, as soon as the .Net 6.0 is out, .Net5.0 should not be supported anymore since the .Net6.0 is the LTS (the .Net5.0 being a short-lived version).

So far so good: let's multi-target the stack (as we've done for years - net461/netcoreapp1.0/1.1, etc.)... Yes... But... We would like to provide a TRUE LTS support: an application running on netcoreapp3.1 MUST NOT depend on any v5 dlls. And to ensure this... SUPRPRISE... we need to get rid of all the "netstandard" targets!

Why this? Because as soon as a component is "netstandard", then its dependencies can only be in a single version, there cannot be any conditional dependencies based on the "TargetFramework". Since we want to stay on the safe side, then we must not introduce for instance a dependency on "Microsoft.Extensions.Primitives/5.0.0" in a netcoreapp3.1 deployment (we are currently using the 3.1.10 and will use the 3.1.11, 3.1.12 etc. LTS versions). Ensuring this "quality" in the dependency hell requires to kill any "netstandard" intermediate abstractions...

Does it mean that NetStandard is dead? What do Microsoft say about this? Their current answer is funny: https://docs.microsoft.com/en-us/dotnet/standard/net-standard#net-standard-not-deprecated
My understanding is that it is not deprecated because it enables the support of de facto deprecated platforms :-).

So, yes, we will support .Net5 for a short time and then .Net6 as soon as it is out and those 2 a long as they are alive: see here https://dotnet.microsoft.com/platform/support/policy/dotnet-core

[clegendre]

Thanks you for the detailed answer.
We cannot multi target CK-AspNet because it depends on some netstandard projects, sad!

So, there will be a one-shot move to net5.0 tfm for the whole CK-Stack.
Do you have an estimated ETA for this?

[olivier-spinelli]

I'm thinking that a required step is to decide whether SOME packages should remain in netstandard and WHERE they should be. These are the packages that have NO dependencies or depend only on other pure netstandard packages (Motivation: avoiding multi-targeting that is more expensive to build/generate and maintain when possible).

Mixing this kind of projects with "normal' (ie. multi-targeted) ones annoys me. I'd like to have a minimal tooling to check that the dependencies are "clean".

One approach would be to consider that the CK-Build stack (that currently only contains CSemVer, CodeCake and SimpleGitVersion) being the "base stack" can contain other "netstandard" packages (typically CK.ActivityMonitor, CK.Core and CK.Text): this way all netstandard are in CK-Build, and CK is fully multi-targeted. But, where should CK.UnitsOfMeasure be? This is a very basic package with no dependency but it has nothing to do with any "Build" aspect.

I'd rather mix the packages... but we just need a way to check the dependencies. CKli can do this; I worked on this recently: https://github.com/CK-Build/CKli/tree/develop/CK.Build.Artifact.Cache
It appears to work (it needs to handle "package unlisting" though) and can help support the feature, but there is work to be done.