Aspnet core attribute decorator not working after upgrade to v1.1.0 The controller never execute.

[irowbin]

Works in v1.0.3 but after upgrade, not working. By downgrading to v1.0.3 works well, but v1.1.0 have some issue.

[commonsensesoftware]

I'm going to go out on a limb and assume you haven't looked at the release notes or the updated wiki. Not to worry, you're not the first. There is a behavioral change for ASP.NET Core that requires this in your setup now:

app.UseMvc();
app.UseApiVersioning();

I'm guessing that you don't have that, but if you add it to your configuration, things will start working again.

Since so many people are getting tripped up by this, I'll investigate whether there is a way to cause a runtime failure if it's missing and publish a patch. Let me know if this is not the problem. Thanks.

[walik92]

Irowbin is right, the latest version v1.1.0 not working

[commonsensesoftware]

I'm going to need more detail than simply "it's not working". Did you update your startup configuration to include app.UseApiVersioning()? What behavior are you seeing? Are you getting 400, 404, 500, or what?

[irowbin]

I've added this to the startup class as well.

app.UseMvc();
app.UseApiVersioning();

I followed the release notes before upgrade to v1.1.0; No exceptions, nothing. If i navigate something like
api/v1.0/controller/method where i decorate with attribute, my controller never got hit. The same config except app.UseApiVersioning(); works well under v1.0.3. Thanks.

[irowbin]

startup class

public void ConfigureServices(IServiceCollection services)
{
    services.AddApiVersioning(config =>
    {
        config.DefaultApiVersion = new ApiVersion(1, 0);
        config.AssumeDefaultVersionWhenUnspecified = true;
        config.ReportApiVersions = true;
    });
    services.AddMvc();
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Account}/{action=Index}");

        routes.MapSpaFallbackRoute(
           name: "spa-fallback",
           defaults: new { controller = "Home", action = "Index" });
    });
    
    app.UseApiVersioning();
}

controller

[EnableCors("AllowAllOrigins")]
[ApiVersion("1.0")]
[Route("api/v{version:apiVersion}/[controller]/[action]")] // <-- domain.com/api/v1.0/controller/get
[CustomExceptionFilter]
public class SearchController : Controller
{
    [HttpGet]
    public IActionResult Get([FromQuery] SearchDto search)
    {
        var content = _service.Search.Get(search);
        return new ObjectResult(content);
    }   
}

This config works under v1.0.3 except app.UseApiVersioning(); but not to v1.1.0 by including app.UseApiVersioning();

[commonsensesoftware]

... and the fog begins to dissipate...

Your application appears to have both UI and APIs. That's is a supported scenario and I've even added acceptance tests for that, but there are still edge case scenarios. It would seem that this is one of them due to the use of the MapSpaFallbackRoute. My understanding of the implementation is that it defines a catch all route token {*clientRoute}.

Let me try to explain why this worked in 1.0, but not 1.1. In 1.0, I was under the impression that the IActionSelector was only called once by the routing infrastructure. In most cases, this was true, but not all. This resulted in some candidates never being considered because the entire selection process short-circuited too early. It would possible to support on matching a result in a single pass, but that would break other features such as reporting all API versions (which are aggregated from candidates) and 400 responses for unsupported API versions. To address this, API versioning needs it's own catch all route of sorts. In fact, that was even a suggestion by the ASP.NET team. I didn't quite like the idea of a special catch all route. Instead, I decided to use a custom router as the catch all, which uses assumed data collected from previous routers and makes a final decision. This is what UseApiVersioning actually does. This hides a bunch of internal mechanics, but does have a dependency on configuration order.

How does all this play into the mix? UseMvc builds an aggregated router for all MVC routes - UI or API. This also includes the support for defining custom user routes, which is where MapSpaFallbackRoute fits in. UseApiVersioning adds a new router to make the decision after this process. Since MapSpaFallbackRoute defines a catch all route token, it short-circuits the pipeline. The API versioning policy never gets a chance to evaluate. This would also explain why you never see the API controller execute.

So how do we address this? I haven't tried it yet myself, but I believe MapWhen will resolve your issue by ensuring the API routes are never considered for SPA controllers. Issue 973 in the JavaScript Services repo describes how to do this. I suspect that it should be a pretty small change for you. If you still can't get it to work, I'm happy to continue sorting it out with you by creating my own repro.

[irowbin]

So i how do i configure the SPA routes to include API versioning? I have both mvc view to run SPA app and API to handle data. It would be helpful if any example is provided including MapSpaFallbackRoute with UseApiVersioning Thanks. @commonsensesoftware

[irowbin]

Getting 404 with any request. No exceptions.

    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Account}/{action=Index}");
    });
    app.MapWhen(x => !x.Request.Path.Value.StartsWith("/api"), builder =>
    {
        builder.UseMvc(routes =>
        {
            routes.MapSpaFallbackRoute(
                name: "spa-fallback",
                defaults: new { controller = "Home", action = "Index" });
        });
    });
   app.UseApiVersioning();

It means we can't use MapSpaFallbackRoute and app.UseApiVersioning() to the SPA app after v1.1.0 upgrades or there might be a complex configuration then this? I will stay with the v1.0.3 until someone finds the solution. Thanks

[exiled78]

Me too. [Now Resolved]

[commonsensesoftware]

Thanks for confirming. That's basically what I was looking for. Since that combination still doesn't seem to work, I'll start putting together a repro. If you already have something you can share, that would be great. I'll update the thread once I have more details.