Support .NET Standard 2.0

[galvesribeiro]

Proposed change

The changes involved to support this features are mostly:

1. Add a new target netstandard2.0 or netstandard2.1 (open for discussion) to the csprojs
2. Implement some attributes used across the codebase which are only available on monikers > net60 as internal. Those would be guarded by #if NETSTANDARD2_0 directives.
3. Add extra Nuget packages which contains missing types back ported to netstandard2.0 such as System.Text.Json, System.Threading.Channels, System.Memory, etc. Those would be added as a dedicated ItemGroup in the csproj guarded by Condition="'$(TargetFramework)' == 'netstandard2.0'" so they aren't needed unless the consumer also target netstandard2.0
4. In some rate spots, some changes has to be made by using #if on some types or method signatures which are not supported entirely in .Net. For example the SslClientAuthenticationOptions which were introduced recently. We could have an #if to replace that implementation with the older Ssl types and implementation.

Use case

The major reason (in my case) right now is to be able to support Unity game servers to use NATS. I was recently forced to use the legacy client because this new one does not support netstandard2.0.

In .Net world, authors usually prefer to make their libraries targeting netstandard2.0 in order to have their libraries widely used. There are however, optimizations only available on certain monikers like net6, net8, etc. Although those are not natively added to netstandard2.0, they are added as packages. This is the model where .Net team adds new features to the standard without breaking the standard itself and that is being working well so far for libraries/features they push and the community-driven ones as well. Also, netstandard2.0, as of now, is the most stable API surface in the whole .Net ecosystem, meaning that we are safe to rely on it as there will be minimal friction to maintain.

Unity has support to netstandard2.1. Although 2.1 support would cover the use cases for game servers, we may have access to other platforms that Today is only supported by the old .Net Clients by targeting net standard 2.0.

Contribution

I'd like contribute a PR with the mentioned changes making the new NATS client compatible with netstandard2.0 as it gives access to more people to NATS server. If for any technical reason 2.0 is not feasible, 2.1 would suffice, making at least Unity game servers (and other apps targeting 2.1) capable of leveraging NATS).

[mtmk]

I think 2.0 makes sense since there doesn't seem to be much difference in supporting 2.0 and 2.1 effort wise.

edit I've done a quick 'unofficial' analysis here mtmk/nats-net-v2-std#1 the idea is to get a feeling that this is possible and we can manage it going forward. comments are always welcome of course.

[teo-tsirpanis]

I noticed that the project is using some APIs that exist in .NET Standard 2.1 but not in .NET Standard 2.0. Some of these cannot be polyfilled efficiently or easily on earlier frameworks.

My suggestion is that if you want to target Unity you should definitely target NS2.1 to take advantage of the newer APIs, and bother with NS2.0 only if you need to support earlier versions of Unity, or .NET Framework.