[Feature]: Cross target .NET 8.0

[iamcarbon]

Is there an existing issue for this?

• I have searched the existing issues

Feature Description

Once .NET6.0 goes out of support in November, we should consider targeting net47 and net8 ONLY, and removing the .NETSTANDARD targets. The remaining targets (outside of NET462+ and .NET8+) will no longer be supported after November.

Motivation

No response

Code of Conduct

• I agree to follow this project's contribution guidelines

[canton7]

Just to add: there's no harm in targeting an old version of .NET for a library. The library will run on whatever runtime the user compiles their application for.

Targeting .NET Standard 2.0 just means that you will run on the set of APIs available on .NET Standard, and anything later. It does not mean that this library requires some old version of .NET in order to run. If it can run just fine on .NET Standard 2.0, there's absolutely nothing wrong with continuing to target it. That way, you continue to support anyone stuck on .NET Standard (including Mono, Unity, Xamarin, etc etc, although I'm not sure whether Yubikey supports those anyway!), as well as everything which comes after, including the latest .NET version.

Using an old out-of-support version of .NET is only a problem for applications. It's not a concern for libraries. If an application targets .NET 6, then it will only run on .NET 6 (ish, rollForward notwithstanding). If a library targets .NET 6, it is able to run on .NET 6 and later, depending on what the application which includes this library targets.

[iamcarbon]

Hi @canton7, while newer frameworks will run against the .NETStandard2.0 abstraction, it's no-longer necessary when targeting .NETFramework and .NET{5+} directly.

Unless the library intends to explicitly support Unity, Xamarin [1] (which has reached end of life), and Mono [2] (with their last major release in July 2019, and recently donated to the Wine Project), keeping the .NETStandard2.0 target may create a false sense of support for these runtimes.

Of course, if the library intends to continue to support Unity, or any these legacy runtimes -- the target should be kept.

[1] https://dotnet.microsoft.com/en-us/platform/support/policy/xamarin
[2] https://www.mono-project.com/

[canton7]

keeping the .NETStandard2.0 target may create a false sense of support for these runtimes.

That's not normally a concern. Targetting .NET Standard 2.0 just means that you only need the set of APIs available in .NET Standard in order to run. If you don't need APIs which are only available in later .NET versions, there's normally no need to target them.

(That's not quite true: there are some areas where you'll get access to slightly better-performing method overloads etc if you target a newer .NET version, but most of what Yubikey does is working against Windows/etc APIs).

I don't think there's any need to target a newer .NET version just because .NET Standard is old, or various .NET versions are going out of support. Like it or not people are stuck on old .NET versions (I've spoken to 3 already this week), and the only effect of targeting a later .NET version when you don't actually need to is that you break those people.

[DennisDyallo]

Hi guys! I just want to say that I really appreciate the discussion this far.
As the sole maintainer of this project at the moment, it's difficult to say what and when, but I definitely want to get off .NET Framework for the newer APIs, language version and performance offered by net8 and net9 (soon to come). I've been reading Msf/Dotnet documentation articles all day (e.g. this one). According to the referenced article, it doesn't seem like there's much point in changing target framework moniker (TFM) to .NET8 over netstandard2.0 for the end user.
What I would like to achieve are two things:

1. Easier maintainability
2. Happy users

Options I see are a) using the PolySharp library, developed at Microsoft by Sergio0694 and supposedly used within the Microsoft Store (which is an UWP project) which would make development easier in the short to medium term, but not any new API or performance benefits, at the cost of adding a third party lib. Or b), dividing the codebase, having net8 targetted code base, while keeping the old one for in order to still support Windows, which .NET Framework is practically a part of)

There are also ongoing discussions to align the .NET SDK better with the structure in the Android SDK and the Swift SDK.

I want you to know that your discussion has been noted and used in internal communcations as to what our strategy is moving forward, so please don't hesitate to continue discussing, asking questions or suggesting guidance.