Consider replacing netstandard2.0 with netstandard2.1 in the next major version

[aqeelat]

Proposal

Consider replacing the netstandard2.0 target in Microsoft.OpenApi.csproj with netstandard2.1 in the next major version.

The package currently targets netstandard2.0;net8.0. Moving the lowest target to netstandard2.1 would make default interface members available across the non-net8.0 target and could simplify part of the public model surface.

Motivation

The codebase has several temporary compatibility interfaces for members that could not be added to existing public interfaces during a minor release:

• IOpenApiSchemaMissingProperties
• IOpenApiSchemaWithUnevaluatedProperties
• IOAuth2MetadataProvider

These interfaces are documented as temporary and intended to be collapsed into the main model interfaces in a future major version. For example:

/// TODO: Remove this interface in the next major version and merge its content into IOpenApiSchema.

With default interface members, properties such as Anchor, Contains, If, Then, Else, DependentSchemas, PropertyNames, ContentSchema, ContentMediaType, ContentEncoding, MaxContains, MinContains, UnevaluatedPropertiesSchema, and OAuth2MetadataUrl could be added directly to IOpenApiSchema / IOpenApiSecurityScheme with default implementations.

That would reduce the need for casts such as:

(schema as IOpenApiSchemaMissingProperties)?.Anchor

and make the model surface easier for consumers to discover and use.

Compatibility tradeoff

This would still be a major-version compatibility decision. Dropping netstandard2.0 would drop .NET Framework and other netstandard2.0-only consumers from the next major version. Those consumers would need to stay on the current supported major version.

That tradeoff may be acceptable for a future major version, especially since this repository's support policy is already aligned with .NET / ASP.NET Core version support windows. However, it is a maintainer/product decision rather than a purely technical cleanup.

There is also an API-shape question: adding netstandard2.1 as another target, for example netstandard2.0;netstandard2.1;net8.0, would only help if the package intentionally exposed different public APIs per target framework. If the maintainers prefer a consistent API surface across TFMs, then the cleanup likely needs to wait until netstandard2.0 is removed entirely.

Secondary cleanup opportunities

Moving the minimum target from netstandard2.0 to netstandard2.1 may also unlock smaller cleanup opportunities such as improved nullable annotations on BCL APIs, Range / Index, and APIs like HashCode.Combine. These are secondary benefits; the main motivation is simplifying the temporary interface shims in the public model surface.

Context

• Removal of .NET Framework support? #751 requested that .NET Framework support not be dropped; netstandard2.0 was the compromise at the time.
• Enable null reference types on next major version #1202 enabled nullable reference types on v2 without changing target frameworks.
• Feature: Resolve $dynamicRef against $dynamicAnchor in the schema reference resolution pipeline #2911 touches schema reference behavior where the shim interfaces add friction, for example Anchor living on IOpenApiSchemaMissingProperties instead of IOpenApiSchema.

Questions for maintainers

• Is there appetite for replacing netstandard2.0 with netstandard2.1 in the next major version?
• If not, would target-specific APIs for netstandard2.1 / net8.0 be acceptable, or should the package keep one consistent API surface across TFMs?
• Is the intended next-major direction still to collapse these temporary interfaces into IOpenApiSchema / IOpenApiSecurityScheme?