Increase framework requirements to net461, netstandard2.0

[bgrainger]

The current TargetFrameworks are net45;net46;netstandard1.3;netstandard2.0.

Now that .NET Core 2.1 and Span<T> have been released, I'm considering whether it's time to drop netstandard1.3 and raise the minimum .NET Framework to 4.6.1.

System.Memory has net461 as an explicit dependency. And despite what the docs say (maybe I'm doing something wrong?), DbColumn appears to be available in .NET 4.6.1, which would remove the need to shim it. Meanwhile, dropping .NET 4.5 saves a lot of code: bgrainger@f104e71

As per https://twitter.com/Nick_Craver/status/1001272947032711168 it may be time to standardise on netstandard2.0 in the ecosystem. Amazon Lambda now supports .NET Core 2.0; it seemed to be the biggest reason people were using netstandard1.3 previously.

For all these reasons, it seems beneficial to move to net461 and netstandard2.0. Please reply if you would be negatively impacted by the removal of netstandard1.3, net45, and net46 support from MySqlConnector.

[VitaliyMF]

I think it is good idea to keep builds for netstandard1.3 / net45 (maybe, with reduced API), as this allows to use MySqlConnector even in legacy projects. Personally I still have .NET Core 1.1 webapp which uses MySqlConnector; I planning to upgrade it in future, but currently it just works and it is cool that I can update dependencies to get latest fixes.

As .net components developer (I use MySqlConnector in some examples) I have feedback from many customers, and reality is that still a lot of people use legacy targets (net45) for various reasons. I'm trying to have netstandard1.5/net45 targets in my components. It is possible to organize code without messy conditional compilation everywhere - instead of that target-specific code can be concentrated in special extension methods, that have different implementations for legacy targets, for example: https://github.com/nreco/data/blob/master/src/NReco.Data/NetStandardCompatibility.cs .

[caleblloyd]

What about cutting a netstandard1.3 branch and releasing 1.x for the current library that targets netstandard1.3. Only make security or critical bugfixes going forward.

Then master would start releasing to 2.x, initially publishing 2.0.0-previewX releases. Move the requirement up to netstandard2.0/net461 and do active development here.

This would provide users of older frameworks an option, while allowing us to avoid messy conditional compilation.

[bgrainger]

Something I forgot to mention in my OP is that Encoding.GetString(byte*, int) doesn't exist in net45; that was added in net46. That's the biggest thing that would need to be shimmed to make ReadOnlySpan<byte> work on net45.

Encoding.GetString(ReadOnlySpan<byte>) exists in netcoreapp2.1 but on downlevel frameworks you need to shim it with the byte* overload (which isn't in net45): bgrainger@d9a39a4#diff-53de8342e3f0891ae6df967ec88ce1d5R36

[bgrainger]

MySql.Data supports netcoreapp2.0, net452, netstandard1.6, netstandard2.0.

It'd be really nice if NuGet could provide data (even if only to the package owners) on which platforms were actually being targeted when the package is downloaded.

[bgrainger]

While writing (for example) new ReadOnlySpan<byte> code (that will really shine on netcoreapp2.1) I've been able to find decent ways to shim the functionality I need on net45 and netstandard1.3 (although sometimes it may require a temporary byte[] allocation if APIs that operate on byte* aren't available). The cost of building and testing on those frameworks isn't high, so I'll keep supporting them for now.