aspnet-api-versioning: Versioning Gets Ambiguous Routes in Core 2.2

When using the Versioning system with a Core 2.2 Preview project, the routing can’t differentiate by version #'s if you use the 2.2 Compatibility Flag (it’s not required that you leave Core 2.2, just set the compatibility flag to 2.1):

    public void ConfigureServices(IServiceCollection services)
    {
      services.AddApiVersioning(opt =>
      {
        opt.DefaultApiVersion = new ApiVersion(1, 1);
        opt.ReportApiVersions = true;
        opt.AssumeDefaultVersionWhenUnspecified = true;
      });

      services.AddMvc()
        .SetCompatibilityVersion(CompatibilityVersion.Version_2_1); // <--- Works 
        //.SetCompatibilityVersion(CompatibilityVersion.Version_2_2); // <--- Doesn't Work 
    }

I tried both the 2.1 version of the library and the 3.0-beta-1 and got same result.

My controller looks like this:

  [Route("api/[controller]")]
  [ApiController]
  [ApiVersion("1.0")]
  [ApiVersion("1.1")]
  public class ValuesController : ControllerBase
  {
    // GET api/values
    [HttpGet]
    [MapToApiVersion("1.0")]
    public ActionResult<string> Get()  => "1.0";

    [HttpGet]
    public ActionResult<string> Get11() => "1.1";

  }

Here is a minimal repro case for you to try:

ReproVersioning22.zip

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 2
Comments: 17

Most upvoted comments

3.1 has been published and includes support for Endpoint Routing. All of the sample applications have been updated to use Endpoint Routing by default as well. Thanks.

commonsensesoftware on Dec 22, 2018

Been revisting this. It’s been a while since I last sync’d up with the ASP.NET team so I needed to refresh my memory of the changes. Since the routing system is completely changed, there is definitely quite a bit of refactoring to do on my side to match with the intrinsic 2.2 features; in particular, the new Endpoint Routing feature. The biggest challenge for me will be deciding whether to continue supporting the legacy style of routing which will still be available. It seems like leaving the legacy support makes sense until ASP.NET Core 3.0 and perhaps then retire it. I also need to figure how to detect which style of routing is being used and alter the setup accordingly as it’s quite different.

I don’t believe the coding effort is all that huge, but the addition of new acceptance testing may be signficant. Depending on the effort required to switch between routing styles will drive my decision to release API versioning 3.0 with it’s current routing capabilities and add the new capabilities in 3.1 shortly thereafter or try to incorporate the changes prior to the 3.0 release. The other consideration is that taking on the new routing features will also require developers to upgrade to ASP.NET Core 2.2. These decisions are more strategic than technical, but it’s a lot to handle as a one-man show.

In the meantime, my understanding is that you can use 2.2 with API versioning, but only using the legacy routing features. This can be achieved with:

services.AddMvcCore( options => options.EnableEndpointRouting = false );
// OR
services.AddMvc( options => options.EnableEndpointRouting = false );

This option trumps the implicit Compatibility Version setting as long as it’s supported (e.g. setting this to true in 2.1 wouldn’t do anything)

That’s the current state of the union. I’ll see if I can’t get some time with the ASP.NET team to mull over some decisions. Ideally, my goal is to coincide the official API Versioning 3.0 release with the ASP.NET Core 2.2 release later this month (they have officially said Q4 2018).

commonsensesoftware on Dec 2, 2018