I\'m trying to hook into the ExecuteAsync()
call that renders a razor page using my CUSTOM view page (that inherits from RazorPage
). In the
Ok, looks like you have to use ViewResultExecutor
. After more spelunking through the code, I found that an executor was used to call the first ExecuteAsync()
in a chain of nested ExecuteAsync
calls. ;)
public class MyViewResultExecutor : ViewResultExecutor
{
....
public override Task ExecuteAsync(ActionContext actionContext, IView view, ViewResult viewResult) ....
....
}
....
services.TryAddSingleton<ViewResultExecutor, MyViewResultExecutor>();
The ViewResultExecutor
service object is obtained in ViewResult.ExecuteResultAsync(ActionContext context)
.
The great thing is you can also access your custom page type through the view
parameter ((view as RazorView)?.RazorPage
). ;) (though, of course, you'll have to cast it to your custom type)
(I started a discussion here originally if anyone is interested to read a few more details on the ASP.Net Core MVC Source side of things)
Update: This process has changed since this was originally posted. This is the new way to register your own executor:
services.TryAddSingleton<IActionResultExecutor<ViewResult>, MyViewResultExecutor>();
// ... or ...
services.TryAddSingleton<IActionResultExecutor<PartialViewResult>, MyPartialViewResultExecutor>();
Please notice the TryAdd
part. That means it will not add it if it already exists. This is the same thing the MVC code tries to do, so you must register yours FIRST before MVC does. Also, if deriving from ViewResultExecutor
(instead of the interface it implements) the {ViewResultExecutor}.ExecuteAsync(...)
signature has changed and can no longer be overridden. You can only override the base {ViewExecutor}.ExecuteAsync(...)
method now.