[RFC] Target framework support

[drieseng]

SSH.NET has always supported a broad set of target frameworks. Even though this is important to our users and myself, our code base and release process are more and more hindered by this ideal.

Therefore I'd like to question whether we should continue to support the following target frameworks:

• .NET Framework 3.5
• Silverlight 4
• Silverlight 5
• Windows Phone 7.1
• Windows Phone 8.0
• Universal Windows Platform 10 [1]

Some of these target framework are no longer supported by Microsoft and require software that is no longer available for download.

This is by no means an announcement to drop support for these target frameworks, but it should be clear that the continued support comes with a cost.

The time I or anyone can spend on this project is limited. Any means to reduce complexity contributes to efficiency, and in turn brings profit to the SSH.NET user base.

I'd like to use this issue to sollicit feedback from our users as to how important it is to continue support for the afore mentioned target frameworks.

I encourage you to be vocal!

Thanks!
Gert

[1] UWP 10 - even though it can hardly be considered legacy - is not (or does not appear to be) supported in SDK projects. If someone can assist us with this, we can continue to support it without much extra effort.

[darkoperator]

Im all for dropping the old frameworks. As you mentioned it takes time away from adding and fixing issues. Faster release cycles means over a million users of my PowerShell module can get the latest and greatest faster plus I can address faster their request for more modern frameworks so for me it is a win win.

[chrgraefe]

Please go ahead and drop support of this TFMs.
You can branch it, if anybody needs it for fast code checking or forking. In rare cases it might be useful for backporting things, but this should be an exception.

[brent-williams]

Strongly in favour of dropping older platforms. If even MS has dropped support, let alone the software can't be downloaded, then surely you're in good company to do the same if it's hindering development on current platforms.

[rjvdboon]

It seems to me that anyone still targeting those obsolete platforms is unlikely to upgrade their dependencies.
B.t.w. how many acknowledgements do you need before deciding that the 2.0.0.0 release will have a more limited (saner) set of target frameworks? The major release you are preparing would be the perfect cutoff point for the reduction in TFMs.

[mrjfalk]

I'm still using the library while targeting Universal Windows Platform 10, and just updated to latest beta version. Would be great if UWP support could remain. Although as you also target .NET standard 2.0 that would probably be enough seeing that works for many versions of UWP as well.

[jimbobmcgee]

Just my two cents, but I would appreciate you continuing at least some support (even if just limited to viable security fixes) for .NET 3.5, as this is still an installable feature for in-support Windows Server versions (e.g. 2016, 2019).

[FaFre]

The project seems to be widely compatible with .NET 5.0, I have an experimental branch for that: https://github.com/FaFre/SSH.NET (just using the main library)

Just had to drop support for RIPEMD160, since it's not supported by .NET any longer. Everything else should be fine, although I didn't spend time on getting the tests to run, as I'm just using it for SSH-Shells and that is working as expected.

Just want to let you guys know... don't know if .NET 5 is even an option for the project.

[binamonk]

Silverlight is about to expire next year so we can drop this support also Windows Phone is gone too.

With the new release schedule for .Net the support for the new frameworks could be limited to LTS releases of .Net Core/5+ and only if necessary.

[NoahLerner]

Just putting it out there that the legacy frameworks are preventing me from actively contributing to this project. When will a final decision be made on this? @drieseng will you consider at least opening a branch with the legacy frameworks removed? Thanks

[jscarle]

With the release of .NET 5.0, the messy API fragmentation that was created between .NET Standard 2.0, the continuation of .NET Framework to 4.8, and the split of .NET Core to 3.1, will finally be a nightmare we can forget.

Considering that the lineage of .NET Standard into .NET Core into .NET 5.0 is a straight line (more or less) and that the only real black sheep is .NET Framework 4.8 (considering .NET Standard supports up to .NET Framework 4.7.2), I've personally stopped supporting anything other than .NET 5.0 and .NET Framework 4.8.

Moving current projects forward in either one of those two directions is very straight-forward and requires very little (if any) code refactoring. The biggest work is moving between the .NET Framework and .NET Standard / .NET Core / .NET 5.0 lineages.

So, I vote drop anything that's old, especially if it's out of support. If developers don't want to move forward, it's that they've accepted the feature set and bugs they live with. So for the same reason, they should accept the feature set and bugs of the last available release for their version of .NET.

Supporting such old .NET versions is a valiant, albeit futile effort.

[agovande]

I am all for not supporting older .NET framework. From my experience I see no issue dropping support for listed target framework. Recently I am receiving more and more request for supporting .NET Core that gives platform independence. Current release of .NET5.0, and supporting it will be step in right direction and future support for framework will be streamlined.

[WaldenL]

I'm all in favor of dropping "old" frameworks. But I'll put in my two cents that we can't lose sight of Framework 4.8. There are many major systems that use WebForms (even if just tangentially) and there is no migration path for those systems to .NET 5. Framework 4.8 will be here for a while, but older stuff? Toast it!

[Jaegermeiste]

Drop everything legacy except UWP - UWP is getting a second wind and is important for modern Windows apps going forward, as well as Xbox.

[Zastai]

Note that for older .NET frameworks at least, you only need to add

    <PackageReference Include="Microsoft.NETFramework.ReferenceAssemblies" Version="1.0.0" IsImplicitlyDefined="true" PrivateAssets="all">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
    </PackageReference>

(or a later version; I see there have been 1.0.1 and 1.0.2 releases very recently.)

This enables targeting .NET framework using only the .NET Core/5+ SDK. It provides reference assembler for .NET Framework 2.0 onwards. So as long as there is not too much need to use #ifs to conditionalize code/APIs to remain backward compatible, that should allow keeping the 3.5 target (and 4.0 and 4.5, all of which are also out of support) around relatively easily.

I don't know if a similar package is available for Silverlight, or for any of the .NET Framework client profiles. They also feel relatively safe to drop support for.

Same with Windows Phone - no idea if reference libraries are available, or if there is much of an install base left.

As for more current platforms, netstandard2.0 and netstandard2.1 would allow running on .NET Core 2.x or up. While older .NET framework might still be in use (e.g. point of sale devices still running winxp or win7), I'm inclined to think that use of .NET Core 1.x in production is far less widespread. But even then, you could try supporting older .NET Standard versions.
On the Framework side, net472 (and/or net48 if it has APIs you want to use) should be fine in 90% of cases.

Targeting netcoreappX.X or net50 specifically may not be needed, unless there are specific APIs you want to use when they're available.

[IgorMilavec]

I propose to approach this in two phases:

1. Cleanup
2. Expansion

In the first phase we would remove targets that are no longer needed and start targeting:

Library target	Usable for
netstandard1.4	Universal Windows Platform 10.0
net462	.NET Framework 4.6.2, .NET Framework 4.7.x, .NET Framework 4.8
netstandard2.1	.NET Core 3.1, .NET 5.0, .NET 6.0

.NET Framework versions before 4.6.2 will be out of support on April 26, 2022, which, if discussing future plans for SSH.NET is "now". Also, upgrading from previous versions is trivial for application developers and I am not aware of any runtime environment that would require prior versions.

.NET Standard 1.4 would support UWP applications, while not interfering with NuGet package resolution for .NET Framework applications.

.NET Standard 2.1 would serve as a base for future work specific to .NET 6.0, while supporting .NET Core 3.1 and .NET 5.0 while they last.

In this phase we would also raise target C# version to something sensible; maybe C# 8 and start using nameof() etc. The goal here is to implement automatable changes that affect the whole codebase to minimize merge conflicts and a later time.

In the second phase we would start to support .NET 6.0 specific features, try to minimize allocations, support Spans for netstandard2.1, add Nullable support, ...

Some reference links:

• .NET Framework Support Policy
• .NET Standard Implementation support
• Target frameworks in SDK-style projects

[drewfreyling]

Happy for these TPMs to removed from support. I really like how it is obvious what is supported by looking at the readme!

[durranitech]

I vote for removing support for old frameworks

[drieseng]

I'm not saying that this is the right motivation, but I'd at least get down to a list of TFMs that are supported in modern versions of VS. For me this means VS2019 and/or VS2022.

Is it enough to just support .NET Standard 2.0 to begin with? This would work for .NET 4.6.2+, UWP, all versions of .NET (Core), Mono, ...

[IgorMilavec]

Yes, netstandard2.0 would be a good start and we can add netstandard2.1 to support newer features (like done in #907).

[drieseng]

@darkoperator, @darinkes, @IgorMilavec Are you all ok with dropping support for every target framework except for .NET Standard 2.0? Should we push one final release for all target frameworks that we currently support?

As @IgorMilavec mentioned, we'll most likely soon add support for .NET Standard 2.1.

Are you ok with us using Discussions? Would you also like a channel that is less "in the open"? I'm ok with DM (if you ever feel the need to yell at me) if the frequency is kept down.

[IgorMilavec]

I'm all for it. As many users have already requested a new release I think a new NuGet release will be welcome by everybody.

Discussions would be great. Long term I'd like to keep the number of open issues to the minimum and having discussions will also help separate the real issues that should be closed quickly from the more general discussions.

[darkoperator]

Agree with Igor, simplifies everything.

…

On Feb 12, 2022, at 9:57 AM, Igor Milavec ***@***.***> wrote: I'm all for it. As many users have already requested a new release I think a new NuGet release will be welcome by everybody. Discussions would be great. Long term I'd like to keep the number of open issues to the minimum and having discussions will also help separate the real issues that should be closed quickly from the more general discussions. — Reply to this email directly, view it on GitHub <#665 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7IHXKAD2JG5ZWGEWKXM3U2ZRNJANCNFSM4MQWJE3Q>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.

[c0shea]

I'm all for dropping support for the old platforms as long as support for .NET 4.8+ remains.

[p2g-james-parker]

Strongly in favour of dropping older platforms.

[Dean-NC]

Yes, do it.

[IanKemp]

Nuke 'em.

[WojciechNagorski]

I'm interested in contributing to ssh.net and would like to help with removing the old target framework. I have extensive experience in open-source projects, including benchmarkdotnet. Let me know how I can assist. Thanks!
@drieseng

[Dean-NC]

It's alive after another year.

[WojciechNagorski]

I've prepared the first draft PR #1109 to start a discussion on this topic.