Target frameworks

[hazzik]

Currently .NET Core 2.0 has reached the end of life on 1st October 2018

The LTS version available are:

.NET Core 2.1 with EOL date of August 21, 2021
.NET Core 3.1 with EOL date of December 3, 2022

Knowing this information shall we enable builds for .NET Core 2.1, 3.1 and .NET Standard 2.1?

[bahusoid]

It's not that we restrict user to these targets... Do you know of any drawbacks if we don't do it?

[cd21h]

I'd vote for NETStandard2.1 and NET5.

[knuxbbs]

NETStandard2.0 and NET5.

The team should maintain NETStandard2.0 as the lowest common denominator, as it is important to maintain support for .NET Framework applications.

[knuxbbs]

In Immo Landwerth’s words:

So, what should you do? My expectation is that widely used libraries will end up multi-targeting for both .NET Standard 2.0 and .NET 5: supporting .NET Standard 2.0 gives you the most reach while supporting .NET 5 ensures you can leverage the latest platform features for customers that are already on .NET 5.

[hazzik]

The problem with .NET 5 is that it is not LTS. It will reach end of support 3 month after .NET 6 release, so around Feb 2022

[fredericDelaporte]

As long as we want to maintain support for .NET Framework, we should keep a .NET Framework target (currently net461). .NET Standard is not enough to avoid regressions if dropping the .NET Framework target:

• The SqlClientBatchingBatcher is only available when targeting .NET Framework. Some equivalent batcher was supposed to land on .NET Core side at some point, but I have not kept track of it, and we do not have implemented it if it has landed. Anyway, no equivalent is available with .NET Standard. So it would be a possible breaking change, asking users to switch for the GenericBatchingBatcher.
• Some reflection capabilities would be lost, like accessing private members in some contexts. That is something about the ReflectionOptimizer, I have not analyzed what are the consequences from an end user viewpoint.
• The CallSessionContext would use an AsyncLocal member instead of the CallContext. This thing is likely not much used though, it is meant for applications using .Net remoting.
• The WcfOperationSessionContext would be no more available. This one would have no straightforward replacement and could be a blocking breaking changes for some applications.
• A bunch of database drivers would switch from direct references to reflection based drivers. That should not be much an issue though.
• The reflection based driver will no more support being initialized through provider invariant name, which would be a possible breaking change with workarounds.
• Proxies on internal types may no more be available, see here and here.

As long as we keep a .NET Standard 2.0 target for maximum reach, keeping the .NET Framework target does not add much burden, so I do not see a good reason to remove it. Maybe reducing the NuGet size? Is this really an issue?

So for NHibernate 6 I am for targeting net461, netstandard2.0, and net6.0 for enabling use of new .NET features in the NHibernate code base.

[hazzik]

Why wait for NH6? We can add .NET 6 target to next version.

[fredericDelaporte]

For removing netcoreapp2.0 and keeping the target count at three. Removing netcoreapp2.0 would cause breaking changes for .Net core app lower than net6.0 (for Linq-to-nh, but also likely for proxies on internal types), even if netstandard2.0 may replace it. Otherwise we would have to add a fourth target.

[hazzik]

Otherwise we would have to add a fourth target.

I don't see a problem with having 4 or 5 targets. The netstandard2.0 and netcoreapp2.0 could be removed in NH 6, but in 5.next we can add .NET 6 and, probably, .NET Standard 2.1 (depends if it has the same proxy limitations as .NET Standard 2.0 or not).

[hazzik]

We'll stick with following strategy:

• Current 'standard' version
• Current 'lts' version
• Current .NET Framework 4.x

[cremor]

I want to point out that by dropping .NET Standard 2.0 for 2.1 you will loose support for some runtimes, see https://docs.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-2-1. Especially UWP stands out.
I don't use any of those runtimes, so I'm not personally affected, but other users might be.

[bahusoid]

6.0 will drop .NET Standard 2.0

I wouldn't drop .NET Standard 2.0 unless it's really hard to support. As it's the only version that allows to connect both old .NET Framework and .NET (Core).

[hazzik]

Ok, ok, we're not dropping .NET Standard 2.0

[fredericDelaporte]

It seems dropping .Net Core 2.0 can cause issues due to some Microsoft mess with .Net Standard: though theoretically .Net Core 2.0 would remain supported through the .Net Standard 2.0 by NHibernate, apps trying to compile for that target will fail to compile due to System.Runtime.CompilerServices.Unsafe 6.0 or higher refusing it.

We have that dependency according to NHibernate.deps.json. (But at least in 5.4.x, branch, it is still an old enough version to not have the trouble.)

See here about this dependency preventing compilation for netcoreapp2.0 when coming from a netstandard library.

With such pitfall, that means the .Net Standard is near to meaningless. Either we go on targeting both .Net Standard and .Net Core 2.0, or maybe we can drop both. Keeping .Net Standard alone would not allow to still actually support .Net Core 2.0 (and 3.0). The remaining cases that would be supported thanks to it would have quite few usages (provided we keep a .Net Framework target), it seems to me. (Is anyone using NHibernate in a Xamarin app? Well maybe, after all.)

(According to some comments in the linked blog, the same trouble would occur if we were to drop .Net Framework targets, thinking .Net Standard would allow to still support it...)

[cremor]

Nice catch. A few thoughts from me:

I think the most important part ist this:

But at least in 5.4.x, branch, it is still an old enough version to not have the trouble.

As far as I can see, the dependency graph is the following:
NHibernate -> System.Configuration.ConfigurationManager -> System.Security.Cryptography.ProtectedData -> System.Memory -> System.Runtime.CompilerServices.Unsafe
Even the latest version of System.Memory (4.5.5 right now) only references System.Runtime.CompilerServices.Unsafe version >= 4.5.3, which should not yet have that compile time check.
This is different from the situation of the blog post you linked, since there Npgsql directly references a newer version of System.Runtime.CompilerServices.Unsafe.
So unless NHibernate references a newer version of System.Runtime.CompilerServices.Unsafe some day, or the user of NHibernate explicitly updates the transient dependency, it should still work for .NET Core 2.x, right?

Assuming this is actually a problem (or will be a problem some day):

• If you strictly only support the stratey posted by @hazzik that would still be fine since .NET Core 2.x is not supported any more. If you clearly document that limitation than that sould be enough in my opinion. And users of old runtimes can always just stay at old versions of NHibernate.
• Dropping .NET Standard 2.0 not only drops support for older versions of Mono, Xamarin and Unity, but also completely drops support for UWP. I wouldn't bother about old versions of Mono, Xamarin and Unity, same as I wouldn't bother about old versions of .NET. But completely dropping UWP? I have no idea if someone uses NHibernate in UWP, but maybe...