DRAFT: Update to net11

[Youssef1313]

{PR title}

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

Summary of the changes (Less than 80 chars)

Description

{Detail}

Fixes #{bug number} (in this specific format)

[commonsensesoftware]

ACK. Thanks for putting this together. I'm out of town this weekend, but I'll look at this ASAP.

[Youssef1313]

PR is green.

@commonsensesoftware Hopefully the new API is good enough for your needs :)

[commonsensesoftware]

@Youssef1313 this is great. I've been able to incorporate this work into dev/css/v11.

In reviewing where everything stands, there was only one open design issue remaining. Is it still feasible to unseal OpenApiOptions?

If you look at:

• ConfigureOpenApiOptions.cs
• VersionedOpenApiOptionsFactory.cs

It's pretty gross. 🤮 There is a relationship between the built-in options and the versioned equivalent. Since OpenApiOptions is currently sealed, the only option is to bridge the configuration between them through this strange sequence of interdependence. The way I would address this is to have VersionedOpenApiOptions : OpenApiOptions and then register a new IOptionsFactory<VersionedOpenApiOptions>. The existing IOptionsFactory<OpenApiOptions> would be replaced and call through to the versioned variant, which works because the types are now covariant. I've used this approach with success in the past.

It's not a dealbreaker, but if this small change could be made, now is the time. I know you must be entering the RC milestone, but there is no functional change. I would just need the type unsealed. Aside from this one issue, I think I have most everything aligned for the RC and eventual release.

Let me know. Thanks.

[Youssef1313]

@commonsensesoftware I doubt this will fit in .NET 11 timeframe as we are late in the cycle now. RC1 is already code complete, and this will need to go through the API review process. Feel free to open an API proposal, but I feel it's unlikely to change because:

• The case in need to inherit from the options type is narrow (only library usage, not end-user usage).
• That case already has an alternative.

[commonsensesoftware]

@Youssef1313 Thanks. Yeah, I was afraid of that. If you don't think anyone will move, they almost certainly won't. I've filed legitimate bugs that have been open for 5+ years. This would be low on the totem pole. The current situation is less an alternative and more like hack. I can live with it, but it would have been better. Interesting that unsealing would require a full API review since the API doesn't change. I get the desire for more performance, but there should be a really compelling reason to apply sealed on a public type IMO.

I'll leave this PR open until I have the official branch merged. Thanks again for the assist.