Npgsql: Target frameworks

[austindrenski]

Are there still strong reasons to target net45 and net451 in the upcoming release?

The official channels list these as being no longer officially supported.

/cc @roji

[roji]

Not really... the main reason was that continuing to support them doesn't cost us anything.

There's at least one place where supporting only net461 and above would be helpful - it would allow us to use TaskContinuationOptions.RunContinuationsAsynchronously. However this would require dropping net452, which is still supported. To be honest, I don't have a big problem doing that either, but we simply don't seem to have much to gain by dropping these... If you feel otherwise let me know.

FYI there are still quite a few people out there using Npgsql 2.2 because it supports .NET Framework 3.5...! Legacy is a real pain.

[austindrenski]

For net45 and net451 it's just a preference against keeping unsupported SDKs installed. Bumping it to at least net452 seems reasonable in this regard.

It would also cut the build time on AppVeyor if we only needed to test the netstandard2.0 builds.

If we bumped to a net46x, wouldn't the library then just target netstandard2.0?

[roji]

Unfortunately not - Npgsql targets. NET Framework because it supports some APIs which aren't available in .net standard. The main examples are distributed transactions (extended System.Transactions support), Windows performance counters, some Windows specific feature for finding out your username, etc. Targeting only .NET standard 2 would mean dropping all these features.

If we're really concerned about built time, we can always test only .NET Core on Travis and only .NET Framework on appveyor. But I don't thing it's important enough and I prefer that appveyor continue doing both.

We can change to target .NET Framework 4.5.2, sure. Again, it wouldn't give us much really, but I guess we can do it for 4.1. At least we would be targeting only one version of .NET Framework and not two...

[austindrenski]

Ah, right. I wasn't thinking about the API surface. Do you know if those are under consideration for inclusion netstandard3.0 (presumably behind some platform abstraction)?

[roji]

I'm pretty sure they're not... There are some efforts on creating platform-independent versions of these features out (e.g. cross-platform distributed transaction manager) but it's likely that at least in some cases that would be a new API (e.g. performance counters). So we're probably going to be stuck targeting .NET Framework for a long while, unless we really decide to dump those features entirely.

I don't really see a big issue with it - apart from a bit more build time there's little impact. BTW even if we were only targeting .NET Standard 2.0 today, I'd still want to test on both .NET Core and .NET Framework just to be sure...

One question in my mind is regarding the plugins, which currently also target both .NET Standard and .NET Framework. None of them actually need .NET Framework, but I'm not 100% sure about the transitive dependency (i.e. .NET Framework program using Npgsql.NodaTime and Npgsql, the latter targeting .NET Framework but the former only .NET Standard). We should probably be able to stop targeting .NET Framework in the plugins, but we need to test.