Aspnet-api-versioning: Cannot find GetApiVersion()

[milla]

In the sample project "SwaggerSample" it has project reference of Microsoft.AspNetCore.Mvc.Versioning.ApiExplorer, when I tried to replace project reference to nuget package with Microsoft.AspNetCore.Mvc.Versioning (1.0.3 and 1.1.0-beta1), it shows that cannot find GetApiVersion in context.ApiDescription.GetApiVersion() .

Is there anything I missed?

[commonsensesoftware]

You didn't miss anything. I've been using the example projects as part of the long-running feature branch to enlist feedback. Until now, if you wanted to do anything more than just look at the code, you would have had to clone the repo to run the Swagger examples.

A lot of double-checking goes into a release. As coincidence would have it, I literally just published the packages. You can now reference the official NuGet package Microsoft.AspNetCore.Mvc.Versioning.ApiExplorer (Beta 1).

Although it's listed as a beta, I don't expect much to change. I want to give a little of time for people to test it out, report any issues, or provide additional feedback. I expect to promote the packages within a couple of weeks.

[milla]

Cool, thank you. @commonsensesoftware

One more question, I noticed that ApiVersion supports only x.x not x.x.x, the latter causes error. How I can configure to let it support x.x.x version as we have API version like "1.0.3" which shall be reflected in API endpoint.

[commonsensesoftware]

I didn't make up the API version semantics. They are based on the versioning policy defined in the Microsoft REST Guidelines. A lot of work went into make sure things like 1.0-rc > 1.0-beta work. While it possible to extend the ApiVersion class, a bunch of things would likely have to change to make an alternate format work. A few people have asked about this so it might be something considered in the future.

I'm not sure that you have control over it, but in my opinion there is little-to-no need for anything more than the major and minor version using a numeric scheme. Remember that the API version is the version of the service (e.g. the public contract) and not the version of the code that implements it. A build or revision number is not supposed to have any visible changes, which means it's not something a service client should ever care about. Making the underlying code and service versions match is a convenience, but shouldn't be a requirement.

If you _must_ include a version in this format, I know of a few times that have used an internal mapping between the API version and the version they want. This could be achieved with a custom attribute that you apply to your controller or action. It can also be done using some type of dictionary lookup.

That probably wasn't the answer you were hoping for, but hopefully that clears a few things up and gets you a little closer to making things work the way you want.

[milla]

Appreciate 🥇 . For some reason it has to support schema version like 1.0.3 :( I hope the pattern could be extended in the future. I'll take a look if it can be done with a mapper . @commonsensesoftware