Review target frameworks

[alexeyzimarev]

I see that the library targets some legacy .NET Framework versions that aren't supported anymore.

It also limits support for .NET 6+ applications by targeting .NET Standard 2.0, which has a lot of missing features of newer .NET versions like async disposable and passing the cancellation token when reading the HTTP client response stream.

My suggestion is to:

• Drop all the .NET Framework targets except net461, which will be supported until 2027
• Add .NET 6 and .NET 7 as targets
• Keep .NET Standard 2.0

I can submit a PR with the change.

[pransh15]

Hey @alexeyzimarev 👋

Thanks for the suggestion for this. I believe there might be projects with .NET legacy frameworks still using this SDK, maybe @sighphyre can understand this better since I have no experience with .NET or .NET standards.

In any case, it's a really good suggestion to support newer, secure and long-term standards, and maybe we can branch out .NET Standard 2.0 from .NET legacy to support newer projects. What do you think?

[alexeyzimarev]

There might be indeed projects using unsupported .NET versions, but those versions aren't getting security fixes.

I believe it's a good practice to drop the support for unsupported platforms as it might push people to upgrade finally. It's unsafe to execute applications in production that use an unsupported .NET Framework version.

Also, the NuGet package is not going anywhere. People can use the current version until they decide to upgrade. When upgrading the package, they can change the target for their project to .NET Framework 4.7+ as it's fully compatible with 4.5.

[sighphyre]

Hey @alexeyzimarev yeah I agree with your thoughts here, I see we're still supporting targets which hit EOL over 5 years ago, it's probably time to move towards dropping those. But I think this will require a major version bump, because @pransh15 is right here, there might be folks still using those and it feels rude to make changes that cause a project to not compile outside of a major version. What do you think about doing this in two steps? One PR to add support for .NET 6 and 7 and a second to remove the .NET frameworks? I'd be happy with the former right now, there's no real reason not to have support for those and we can do a major version bump directly after the latter? If you're willing to make the PRs it would be insanely appreciated..

Also, roping in @daveleek here for your thoughts

[daveleek]

Wasn't aware the newer .NET frameworks could target older windows framework versions, just assumed a windows framework would be required. That's on me :)

Adding new framework versions seems like a good idea, .NET 6, 7, and isn't there a newer .NET Standard? 2.1? Maybe add that too if possible? From the discussions I've had with @ivarconr on the matter, exactly which .NET versions are in active use by enterprise customers is difficult/tedious to figure out, and we're not super eager to alienate them/force them to upgrade. Thus I think removing support should only be done once we're confident of which to remove with least amount of harm done to customers.

Regarding figuring out which frameworks to drop support for there are a few options, we could add warnings for certain frameworks and we could also include versioning in separate client headers, then try to aggregate that and see what to do, but that's probably a business decision @sighphyre @ivarconr :)

[alexeyzimarev]

.NET Standard 2.1 is as good as dead as it was released together with .NET Core 3.1 to support some new SDK signatures. .NET Standard 2.0 is LTS, and 2.1 is not.

Newer SDK has some improvements that can be relevant and can be fenced with pragma directives. For example, response.Content.ReadAsStringAsync() accepts the cancellation token.

I meant that dropping support for discontinued runtimes is that using such a runtime poses security risks for those who keep using them, and it costs very little to switch the target framework to a newer SDK like 4.7.1 or at least 4.6.1 for those who are still on 4.5.

As you maintain this client as a way to use your commercial product, I am fully aware of the concerns, so it's just a proposal. At the same time, most of the commercial vendors don't support .NET Framework versions less than 4.6.1. For example, Azure and Google libs only support 4.6.1+. At the same time, AWS still supports 3.5 and 4.5.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.