Looks like what you wanted finally happened?

It finally did. Honestly, about a month ago, but I've been up to my eyeballs and hadn't had time to test it would work. This is the exact same packages as what was published in the official 5.1 release, only uploaded to NuGet. It's kind of crazy that it already has that many downloads. This version and all others going forward will have a banner at the top of the README. I just hope people notice. I'm not sure how else to communicate it. It's been over two years, I know there are still people using the 5.x with .NET 5+. No additional work will happen on these versions, save for critical servicing. Since two fundamental areas have been split up into new packages, I can't really resume these package identifiers even if I wanted to.

I updated my .net6 Web API to 5.1.0 but my unit tests started to take a long time (for some reason there is a stack overflow exception that takes a lot of time and then the test host restarts and finishes the tests).

Because of that I started googling and found out about all of this, I had no idea about what happened to the project.

About people noticing in my case it's easier when the package is marked as deprecated, that and the README would make it easier to change to the appropriate version.

Thanks a lot for your work, time, dedication and for keeping this project alive.

Edit: I upgraded to 6.4.0 and I'm getting the same behavior, I'm staying with 5.0.0 until I figure out what's going on.

@JuanZamudioGBM unfortunately I haven't been able to even publish updates until about a month ago. It's taken over 2 years to get to this point. Without the ability to publish, there was no way to update the README to help let people know. I knew that would be problem and fell on many grenades trying to sort it out for the community to no avail. Fortunately, it is finally fixed and people are starting to notice. I hadn't considered formally marking the packages a deprecated, but that's a good idea. I'll look into making sure that I even have the ability to do that. 5.x is the last of the MS packages, but I will consider servicing it.

Since the behavior repros on 5.x and 6.x+, there might be an issue there. If you have the world's simplest repro, open an issue and I can help dive deeper into what's happening.

@JuanZamudioGBM It's also worth mentioning that 7.x is the latest version. 😉

Well, it's just lonely old me here as a mate of one #army-of-one. Thanks for the kudos. It's appreciated and what keeps me going on the project.

1. As you've noted, I have not gotten necessary support from those at MS that can enable me to push or update the old Microsoft.* packages. As a result, I can't even notify people about the changes. I've fought for close to 2 years to make this happen to no avail. Lots of promises have been made, but they all come up short. If enough people in the community complain, maybe it will change. Microsoft.AspNetCore.Mvc.Versioning should be considered dead. Even if I could push to the old packages, I was unlikely to ever be able to push new ones under the same branding. When I thought I would never regain any control, I started the process of breaking things into to new packages. I was close to forking the entire project, but decided it was better for the community to stay in the same repo. I manually published a 5.1 version with some patches, but the 5.x release is only ever intended to support .NET 5. Moving forward (e.g. 6.0+), all packages will be branded as Asp.Versioning.*.
2. I tried to make it clear on the landing page, but there is still some confusion. Here's the breakdown:
   • ASP.NET Web API (.NET 4.5 - 4.8.x)
     • Asp.Versioning.WebApi
     • Asp.Versioning.WebApi.OData
     • Asp.Versioning.WebApi.ApiExplorer
     • Asp.Versioning.WebApi.OData.ApiExplorer
   • ASP.NET Core (.NET 6.0+)
     • Asp.Versioning.Http (core - supports Minimal APIs)
     • Asp.Versioning.Mvc (brings in MVC Core for controllers)
     • Asp.Versioning.Mvc.ApiExplorer (API Explorer support)
     • Asp.Versioning.OData (OData 8.0+)
     • Asp.Versioning.OData.ApiExplorer
3. Asp.Versioning.Mvc depends on Asp.Versioning.Http so if you bring in MVC Core support for controllers, you'll have Minimal API support too
   • It appears you are using ASP.NET Core so you do not want any of the Asp.Versioning.WebApi* packages
   • ASP.NET Web API was a product, whereas you can build a "web API" with ASP.NET Core (thanks MS Marketing >_<)

If you have both Minimal APIs and controllers, that is a supported scenario. If the APIs are across the implementation styles, there's a bit of work to do. If they are separate APIs, implemented in different styles, then there's nothing to do.

For example:

[ApiVersion(1.0)]
[AdvertisesApiVersions(2.0)]
[Route("[controller]")]
public class HelloController : ControllerBase
{
    [HttpGet]
    public IActionResult Get() => Ok("Hello world!");
}

var app = builder.Build();
var hello = app.NewVersionedApi();
hello.MapGet( "/hello", () => "Hello world v2!")
     .HasApiVersion(2.0)
     .AdvertisesApiVersion(1.0);

The reason this is necessary is because collation is performed differently between controllers and Minimal APIs. Routing would not be affected, but reporting API versions would. In order have api-supported-versions: 1.0, 2.0 for both styles of endpoints, you can advertise (a long-time existing feature) version from the other implementation style. If your APIs don't overlap this way, then you're good to go.

Thank you very much for clarification, now it's clear for me. Once again it's shame Microsoft ignores this topic. Actually, I was unable even to find any official MS guidelines for versioning usage (even via old libraries), only some 3rd party articles. What a mess I must say.

There's a broad and long misconception that this project was run or otherwise funded by Microsoft and/or the ASP.NET team. It's not nor was it ever. It was under Microsoft OSS when I was still an employee. I was never even part of the ASP.NET team. That all cast a big shadow. Most posts, videos, and interviews all talk about how some Microsoft team brought it all to light. There's no i in team. Since I've left the company, it has become - sometimes painfully even - that this project is not part Microsoft or ASP.NET. This is why there is no official Microsoft documentation and you won't find anything on the documentation sites. I'm no longer allowed to use Microsoft naming or branding and no one from Microsoft wanted to help carry the torch. All that was really required was to have someone review and approve my releases. 🤷🏽

That being the case, the bandage had to come off at some point. The level of confusion that it has caused is unfortunate, I fought long and hard to transition things the right way. I feared this might happen. Sadly, those fears came to fruition. Nevertheless, people have started to notice the change, make the transition, and spread the word along the way. Thanks for your continued support.

Running, documenting, and supporting this entire project takes quite a bit of time. Things have simmered down a bit. I have some goals to get some articles and videos published in 2023. Stay tuned.

A quick note because I noticed that someone posted a question/comment about AddVersionedApiExplorer, but now seems to have deleted their comment. It also relates to @dozer75's comment about the breaking changes.

The breaking changes between 5.x and 6.x are outlined in significant detail (IMO) in #808. The section Breaking Changes → Configuration specifically calls out the differences in setup and the new IApiVersioningBuilder. If additional information is required or people want to see this information repeated somewhere else (the wiki?), I'm happy to oblige. I'd probably have to reword it a bit as it was written in the context of a roadmap, but now that is simply how it is.

NuGet package manager in VS now shows that Microsoft.AspNetCore.Mvc.Versioning is deprecated and links Asp.Versioning.Mvc as the recommended replacement.

@trlevvis Indeed. I'm not if that is a question or statement. I finally put a migration page based on this discussion. I discovered do have what's necessary to mark the package as deprecated with additional information so I have done so. The README.md in the old packages already said as much, but people have not been reading it. There is still a ton of people using the 5.x.x versions, so hopefully this will help highlight the change and get people to migrate. 😄

Sadly, you can count me among the ones that didn't read thoroughly, but the warning icon and a deprecated tag sure caught my eye.

@trlevvis You're not alone. I spent almost 2 years trying to do the right thing with MS to no avail. I committed to refactoring everything and publishing with new package identifiers Feb '22 (which was the original MS suggestion 😿). Things went official in Aug '22. .NET 5 is not officially supported in later versions (e.g. .NET 6, 7, 8) so I've been trying to come up with progressively increasing ways to get the word out there.