Update the .NET Framework/.NET Standard TFMs to reference ASP.NET Core/Entity Framework Core 2.3 and the .NET Extensions version 8.0

[kevinchalet]

Confirm you've already contributed to this project or that you sponsor it

• I confirm I'm a sponsor or a contributor

Describe the solution you'd like

Last month, ASP.NET Core 2.1 was re-versioned to 2.3 by the .NET team: https://devblogs.microsoft.com/dotnet/servicing-release-advisory-aspnetcore-23/. Going forward, it is expected that security patches affecting ASP.NET Core 2.1/2.3 on .NET Framework will be released as 2.3.x packages.

Unlike the ASP.NET Core 2.1 packages that exclusively referenced the 2.1 version of the Microsoft.Extensions.* and System.* packages, the ASP.NET Core 2.3 packages now reference the 8.0.x version, which will require bumping all the Microsoft.Extensions.* and System.* dependencies referenced by OpenIddict for the .NET Framework TFMs.

While all ASP.NET Core 2.1 are expected to be able to move to 2.3 flawlessly, ASP.NET Core applications depending on the 2.2 packages will be negatively affected, as 2.3 doesn't include any of the changes introduced in 2.2: if we decide to bump the ASP.NET Core packages dependencies in OpenIddict 7.0, any application relying on 2.2-only features will stop working properly.

If you think you may be affected by this change, please post here.

Additional context

No response

[kevinchalet]

Note: this also affects Entity Framework Core 2.1, that was re-released as Entity Framework Core 2.3.

Initial tests indicate that this doesn't negatively impact "legacy" ASP.NET 4.x applications as you just have to regenerate/adjust the binding redirects to account for the bumped dependencies.

They also show that doing that would improve a few things:

• TimeProvider could now be supported on .NET Framework/.NET Standard: removing the #if conditions and making the TimeProvider options non-optional simplify all the call sites... drastically 😃
• System.Text.Json.Nodes could also be supported on .NET Framework/.NET Standard, allowing to remove a huge number of #if guards.
• It would allow using the same IdentityModel version on all TFMs (recent versions depend on .NET 8.0/9.0 packages so they are currently only used on .NET 8.0 and higher).
• We could use the IValidateOptions<T> interface (that wasn't available in 2.1).
• Microsoft.Extensions.Http.Polly 8.0+ targets Polly 7, so we'd no longer need to explicitly reference Polly 7 (the 2.1 package referenced Polly 6).

There are a few concerns, tho':

• While 2.3 is a "minor" release according to the SemVer versioning scheme, it's actually a source and binary-breaking update since none of the APIs present in 2.2 are available in 2.3. OpenIddict itself is not affected at all (since it currently targets 2.1 and thus doesn't use any of the APIs present in 2.2) but it may break final applications forced to move to ASP.NET Core 2.3 due to OpenIddict 7.0+ targeting ASP.NET Core 2.3 in quite subtle ways.
• It's not 100% clear what the update strategy for the ASP.NET Core 2.3 packages will be: will they be updated when .NET 8.0 stops being supported to target a more recent set of .NET Extensions packages? (e.g .NET 10?)
• Despite targeting .NET Framework 4.6.2, Microsoft.Extensions.Http.Resilience, like all the .NET Extensions packages maintained as part of the dotnet/extensions repository isn't officially "supported" on .NET Framework and triggers a warning on .NET Framework 4.6.2+ (that you can opt out using an MSBuild property). While it technically works flawlessly, the user experience would be very poor so we'll keep excluding these packages on .NET Framework (they are also not supported at all on .NET Standard).