kobake / AspNetCore.RouteAnalyzer

MIT License
88 stars 26 forks source link

Does not work with ASP.NET Core 3 #25

Open ugumba opened 5 years ago

ugumba commented 5 years ago

I was able to configure endpoints like this (instead of UseRouteAnalyzer()):

            app.UseEndpoints(config =>
            {
                config.MapControllers();

                // Manually add RouteAnalyzer endpoints
                config.MapControllerRoute("routeAnalyzer", "{controller=RouteAnalyzer_Main}/{action=ShowAllRoutes}");
                config.Map("/routes", context =>
                {
                    context.Response.Redirect("RouteAnalyzer_Main/ShowAllRoutes");
                    return Task.CompletedTask;
                });
            });

But the page rendering fails with

TypeLoadException: Could not load type 'Microsoft.AspNetCore.Mvc.Internal.HttpMethodActionConstraint' from assembly 'Microsoft.AspNetCore.Mvc.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.
ugumba commented 4 years ago

Added #26 incorporating the above and fixing the TypeLoadException. Please review, anyone!

NetTecture commented 4 years ago

Still the same here...

TypeLoadException: Could not load type 'Microsoft.AspNetCore.Mvc.Internal.HttpMethodActionConstraint' from assembly 'Microsoft.AspNetCore.Mvc.Core, Version=3.1.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.

in

AspNetCore.RouteAnalyzer.Inner.RouteAnalyzerImpl.GetAllRouteInformations() AspNetCore.RouteAnalyzer.Controllers.RouteAnalyzer_MainController.ShowAllRoutes() lambda_method(Closure , object , object[] ) Microsoft.Extensions.Internal.ObjectMethodExecutor.Execute(object target, object[] parameters) Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor+SyncActionResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, object controller, object[] arguments) Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeActionMethodAsync() Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(ref State next, ref Scope scope, ref object state, ref bool isCompleted) Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeNextActionFilterAsync() Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context) Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(ref State next, ref Scope scope, ref object state, ref bool isCompleted) Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync() Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Awaited|24_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, object state, bool isCompleted) Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context) Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(ref State next, ref Scope scope, ref object state, ref bool isCompleted) Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeFilterPipelineAsync() Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Logged|17_1(ResourceInvoker invoker) Microsoft.AspNetCore.Builder.RouterMiddleware.Invoke(HttpContext httpContext) Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context) Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

kingrichard2005 commented 3 years ago

Hello @ugumba , for you and anyone else who comes across this, I know this is a little dated, but my team and I were dealing with this exact type load issue this week as part of an effort to migrate some of our legacy aspnetcoreapp services to 3.1 from 2.0. Our "aha" moment came when we reviewed the MSDN 3.0 compatibility docs section below and saw that the Microsoft.AspNetCore.Mvc.Internal.HttpMethodActionConstraint type is among the pubternal apis that are no longer publicly accessible.

https://docs.microsoft.com/en-us/dotnet/core/compatibility/3.0#pubternal-apis-removed

After removing references to the HttpMethodActionConstraint type on our end, the issue no longer cropped up :smile: Looking at the updates you made in the previously PR #26 above, the issue persists b/c those updates still reference the now fully internalized HttpMethodActionConstraint type.

We still needed access to the httpmethod of the ActionDescriptor, so to get around that we instead queried the descriptor instance's (public) EndpointMetadata property which contains the same httpmethod metadata info. You can make a similar change on your end, something like the below example, and that should resolve that typeload exception and still provide the httpmethod info you need

    var httpMethodMetadata = _e.EndpointMetadata.Where(obj => obj is HttpMethodMetadata).FirstOrDefault();

    if (httpMethodMetadata != null)
    {
        var verbMethod = (httpMethodMetadata as HttpMethodMetadata).HttpMethods.FirstOrDefault();
        verb = verbMethod == null ? verb : verbMethod;
    }