[RFC] Target framework support

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.

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.

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.

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.

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.

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.

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).

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.

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.

@drieseng

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

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.

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.

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!

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

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.

I vote for removing support for old frameworks

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, ...

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

@darkoperator

@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.

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.

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.

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

Strongly in favour of dropping older platforms.

Yes, do it.

Nuke 'em.

@drieseng

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

It's alive after another year.

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

Navigation Menu

Repository navigation

[RFC] Target framework support #665

2 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[RFC] Target framework support #665

Description

Activity

darkoperator commented on Apr 25, 2020

chrgraefe commented on Apr 26, 2020

brent-williams commented on Jun 25, 2020

rjvdboon commented on Aug 4, 2020

mrjfalk commented on Sep 6, 2020

jimbobmcgee commented on Dec 8, 2020

FaFre commented on Dec 14, 2020

binamonk commented on Dec 23, 2020

NoahLerner commented on Jan 30, 2021

jscarle commented on Feb 26, 2021

agovande commented on Mar 29, 2021

WaldenL commented on Apr 16, 2021

Jaegermeiste commented on May 18, 2021

Zastai commented on May 19, 2021

2 remaining items

durranitech commented on Feb 9, 2022

drieseng commented on Feb 9, 2022

IgorMilavec commented on Feb 10, 2022

drieseng commented on Feb 12, 2022

IgorMilavec commented on Feb 12, 2022

darkoperator commented on Feb 12, 2022

c0shea commented on Mar 7, 2022

p2g-james-parker commented on Jun 17, 2022

Dean-NC commented on Jul 5, 2022

IanKemp commented on Nov 10, 2022

WojciechNagorski commented on Apr 10, 2023

Dean-NC commented on Apr 10, 2023

WojciechNagorski commented on Apr 11, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions