Does .NET 9's OpenApi support render this obsolete?

[armanossiloko]

In the recently released .NET 9, there's built in support for generating openapi documents. However, these documents have to be predefined by specifying services.AddOpenApi();.

This means that all API document names have to be defined in advance before the IServiceProvider is even built. This seems to totally "break" the flow of the Asp.Versioning.Mvc.ApiExplorer package. If I am not wrong, it was Microsoft themselves who delegated the original Microsoft.AspNetCore.Mvc.Versioning to the community which ended up turning into this aspnet-api-versioning.

Since documents have to be known in advance now and this package was basically providing an IApiVersionDescriptionProvider in runtime, does .NET 9's default OpenApi document generation render aspnet-api-versioning obsolete? None of what Micorosft provided with .NET 9 seems to display proper versioning support at all, just some different ways to generate documents at build time. Is there a way to integrate this with .NET 9's default OpenApi support now or am I missing something here?

[captainsafia]

@armanossiloko There was a little bit of conversation around this issue when I took a stab at updating our eShop sample app, which uses ASP.NET versioning, to use the new OpenAPI package in https://github.com/dotnet/eShop/pull/360#discussion_r1594822030. Ultimately, the (ugly) resolution that we landed on in that PR is to declare the versions up front as you mentioned.

At the time, @commonsensesoftware mentioned having some ideas around API changes to make in Asp.Versioning to support easier resolution of documents. I think I also recall some ideas thrown around for an AddVersionedOpenApi API that would encapsulate the document registration and the versioning pattern in one.

[commonsensesoftware]

@captainsafia Thanks for digging that up and refreshing my memory.

@armanossiloko at this very moment I don't have a working example I can show. What you should need to do is use a IConfigureOptions or IPostConfigureOptions on OpenApiOptions where you inject IApiVersionDescriptorProvider and append the necessary entries. This is effectively the same process that is used with Swashbuckle (which you can see here). I haven't tried it myself, but that should work. I'm actively working on getting a release ready for .NET 9. Thanks for bringing this up. I will look into providing an out-of-the-box integrated solution or, at least, provide an end-to-end example that shows all of the pieces working with the new library. If you find any other sharp edges with what's possible right now, feel free to share or post an issue.

"If I am not wrong, it was Microsoft..."

Actually, you'd be wrong, but that's ok. It's common misunderstanding. I've always been the sole owner, maintainer, documenter, etc of API Versioning. I was once a Microsoft employee so in that sense it was Microsoft. When I left, the transition was less than smooth. There was a lot of things that had to change such as moving the project under the .NET Foundation and renaming packages. All that being said, I've had, and continue to have, a good working relationship with the ASP.NET team, but I've never been part of the team and they've never been co-owners of API Versioning - despite the name. I hope that clears that up. 😉

[robertcoltheart]

What you should need to do is use a IConfigureOptions or IPostConfigureOptions on OpenApiOptions where you inject IApiVersionDescriptorProvider and append the necessary entries.

Looking at the source code for OpenApi, I'm pretty certain you can't do this. AspNetCore adds keyed singleton services keyed by the API name, and registers multiple OpenApiOptions instances, again keyed by API name. Happy to be proven wrong, but I don't think the above will work. See https://github.com/dotnet/aspnetcore/blob/main/src/OpenApi/src/Extensions/OpenApiServiceCollectionExtensions.cs#L55