Getting multiple actions were found exception in Telerik Reporting R1 2022

[Bob]

I am trying to upgrade an ASP.Net MVC (.net framework 4.6.1) application from Telerik Reporting R1 2020 to R1 2022 and can't even get the viewer to display.  The error on screen says

Cannot access the Reporting REST service. (serviceUrl = '/api/reportsapi/'). Make sure the service address is correct and enable CORS if needed. (https://enable-cors.org)

When I open the browser developer tools I see the error has occurred on the call to api/reportsapi/version and the exception message is:

Multiple actions were found that match the request: \r\nFormats on type FWT.MVC.ReportsAPIController

Any idea where to even begin looking?  The prior version worked flawlessly.  We do have a custom report resolver because we change the connection string based on the tenant ID of the logged in user, but I have upgraded that.

[Cris RS]

I'm getting the same problem but with a Web Forms app that is using Web API. (Using HTML 5 Report Viewer) with standard ReportsController.cs

In my Global.asax.cs is this:
protected void Application_Start(object sender, EventArgs e)
{
        RouteTable.Routes.MapHttpRoute(name: "DefaultApi",
            routeTemplate: "api/{controller}/{id}",
            defaults: new { id = System.Web.Http.RouteParameter.Optional });

As soon as I comment this code, reports start working again.

Even if I try to use something different than default route, error popups. Same version R1 2022.

Is this something related with this specific version?

[Bob]

This was a routing issue in Global.asax.cs and the associated RouteConfig.cs files.

 

Edit: Here is what is in Global.asax.cs (relevant part only):

protected void Application_Start()
{
    AreaRegistration.RegisterAllAreas();
    WebApiConfig.Register(GlobalConfiguration.Configuration);
    FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
    RouteConfig.RegisterRoutes(RouteTable.Routes);
}

App_Start\RouteConfig.cs

public class RouteConfig
{
    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
        routes.IgnoreRoute("{*apple}", new { apple = @"(.*/)?apple-touch-icon.*\.png(/.*)?" });
        routes.MapRoute("QuoteView", "qv/{mobileDatabaseID}/{quoteKeyEnc}/{distributionKeyEnc}", new { Controller = "Account", action = "QuoteViewLogin" });

        routes.MapRoute(
            name: "Default",
            url: "{controller}/{action}/{id}",
            defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
        );
    }
}

And App_Start\WebApiConfig.cs

public class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        Telerik.Reporting.Services.WebApi.ReportsControllerConfiguration.RegisterRoutes(config);
    }
}

[Clovis]

How do you fix it? i'm having the same trouble here

[Bob]

See my updated answer.  Hope that helps

[Neli]

Hi Bob,

The problem oftern comes from a greedy route in the routes configuration. I suggest moving the registration of the reporting routes before the default ones, for example, like in the following code snippet:

Telerik.Reporting.Services.WebApi.ReportsControllerConfiguration.RegisterRoutes(config);

config.Routes.MapHttpRoute(
    name: "DefaultApi",
    routeTemplate: "api/{controller}/{action}/{id}",
    defaults: new { id = RouteParameter.Optional }
);

The reason is that this way the reporting route will be prioritized and won't be overridden by the greedy ones. If you don't expose other WEB API routes, you may simply delete the default ones.

This has fixed the issue for other clients who have experienced this error, and I hope it will solve it also for you. 

Please note that there is also a public feedback item that you can vote for in order to increase the priority of the issue - The ApiDefault route registered in ReportsControllerConfiguration.RegisterRoutes hides some routes registered after it.

Please, give this suggestion a try and let me know how it goes.

 

[Bob]

Neli - my issue was solved back in April.  Please see the accepted answer.