Better .Net targets support

[uniblab]

Hi everyone.

One problem I've been dealing with is uplifting the very nice SSH.NET library to support more .net build targets. Ideally I'd like to support all of the .Net Framework 4.6.1+, as well as the .Net Standard 2.0+, .Net Core 3+, and .Net 5+. One issue I've had with this is the build targets for the underlying BouncyCastle.NET Cryptography Library dependency are not very diverse. In some cases there is no exact runtime match and "thunking" and "compatability" is inolved. While perfectly functional, better performce could be had by supporting additional built targets.

So I've created a Pull Request, #610 , which does this nicely. It fully supports all the important targets except .NetStandard2.1 and .Net5.0. The main reasons for this are incompatabilities between .NetStandard 2.1 and quite literally everything else. I hope to tackle .NetStandard 2.1 support very soon since I have a plan for that.

I hope this will generate some interest and maybe put some reviewers on my PR. This tweak is a very useful improvement and aid to my own development not just in supporting SSH.NET, but also in my many applications which depend on both BouncyCastle and SSH.NET.

Thanks!

[Rob-Hague]

Hi @uniblab

I'm sure you're aware of some of this but for the avoidance of doubt:

When a library targets e.g. .NET Framework 4.6.1 (net461) then it is fully compatible with higher .NET Framework versions (net462, net472, net48 etc.).

Furthermore, a target framework in a library more-or-less just defines the API surface that it has access to, not the version of .NET that runs the code. So if your application is running on .NET Framework 4.8, then the code in the library is also executed using 4.8. That means that just adding a target without changing any code in the library does not have any material benefit.

However, even if no library code is changed, adding targets introduces a maintenance burden because of the additional test runs that are required for best practice.

I have to pre-warn you that for these reasons I would most likely not accept a change like #610 into SSH.NET. Of course, if you are just changing your own fork then go ahead and ignore me. I am happy to discuss this or other ideas for SSH.NET in the SSH.NET repo to avoid hijacking this discussion.

Cheers!

P.S. it is not necessary to open a PR, a discussion, and an issue for a change. Normally just one of the three is good enough to start 😉

[peterdettman]

Further to @Rob-Hague's explanation, see https://www.nuget.org/packages/BouncyCastle.Cryptography/2.5.1#supportedframeworks-body-tab and note how many "compatible target frameworks" are covered by a few "included target frameworks".