RTM changes to MvcRouteHandler (and should I use it at all)

[pbering]

Hi,

When upgrading my ASP.NET Core project from RC2 -> RTM I ran into a lot of changes done to the MvcRouteHandler. In RC2 there was an empty constructor but in RTM there is not. I had to change my code like this to use the new constructor: https://github.com/pbering/Lightcore/commit/937a7fe8cd04264110a2252fbc4ee367e3e4ed1f#diff-9529c98fccc3007ae662fcd2a5fb226c

It is working now but my question is more like, is this the correct way to execute a controller action and capture the output added to the response body? My solution to this feels a bit dirty also since the MvcRouteHandler lives in the Microsoft.AspNetCore.Mvc.Internal namespace.

Anyone has any advice on this?

[rynowak]

For your usage I'd suggest using the IActionSelector and IActionInvokerFactory directly. The main tasks that the route handler does are adapting these APIs to the routing system, and diagnostics/logging.

var routeContext = ...;
var candidates = _actionSelector.SelectCandidates(context);
if (candidates == null || candidates.Count == 0)
{
    // No match for the route data - handle this however you want
    return;
}

var actionDescriptor = _actionSelector.SelectBestCandidate(context, candidates);
if (actionDescriptor == null)
{
    // No match for IActionConstraints (like HTTP verb) - handle this however you want
    return;
}

var actionContext = new ActionContext(context.HttpContext, routeData, actionDescriptor);

// IActionContextAccessor is an optional service, you don't need these lines if you're not using it.
if (_actionContextAccessor != null)
{
    _actionContextAccessor.ActionContext = actionContext;
}

var invoker = _actionInvokerFactory.CreateInvoker(actionContext);
if (invoker == null)
{
    // This will only happen if your system is misconfigured - handle this however you want
    return;
}

await invoker.InvokeAsync();

I think your code will be simpler in the end. For instance if you already have the action descriptor of the thing you want to invoke, you could skip the action selector entirely.

Let me know if this doesn't do what you need or if I missed something.

Regarding .Internal - anything in there is subject to change in a future release. We also might make those classes really internal in the future. Some things are there because we know it's not baked yet, and we don't want to live with a bad extensibility point for years. Other things are there because we don't think they are useful outside the framework. So let us know if you feel like something you need to do is blocked by something being .Internal - feel free to just open an issue and show us what you're doing like this one.

[pbering]

Thank you for taking your time to giving me such thorough answer and for giving me a direction for the best way to solve this. 👍

I will try it out asap, thanks again and have a nice day :)

[pbering]

it works, but the IActionInvokerFactory is also in the internal namespace, is there an alternative for that?

[rynowak]

The alternative would be to inject IEnumerable<IActionInvokerProvider> but that API is a bit confusing, you'd end up making a copy of the code inside the invoker factory. I'm going to log an issue to move it to public.