Get all registered routes in ASP.NET Core
I've created the NuGet package "AspNetCore.RouteAnalyzer" that provides a feature to get all route information.
- NuGet Gallery | AspNetCore.RouteAnalyzer ... Package on NuGet Gallery
- kobake/AspNetCore.RouteAnalyzer ... Usage guide
Try it if you'd like.
Usage
Package Manager Console
PM> Install-Package AspNetCore.RouteAnalyzer
Startup.cs
using AspNetCore.RouteAnalyzer; // Add
.....
public void ConfigureServices(IServiceCollection services)
{
....
services.AddRouteAnalyzer(); // Add
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
....
app.UseMvc(routes =>
{
routes.MapRouteAnalyzer("/routes"); // Add
....
});
}
Browse
Run project and you can access the url /routes
to view all route information of your project.
Get all registered routes in ASP.NET Core 3.0
I just want to print them all out.
So, I guess this is for debugging purposes?
In that case, this will get you started:
public HomeController(IActionDescriptorCollectionProvider provider)
{
this.provider = provider;
}
public IActionResult Index()
{
var urls = this.provider.ActionDescriptors.Items
.Select(descriptor => '/' + string.Join('/', descriptor.RouteValues.Values
.Where(v => v != null)
.Select(c => c.ToLower())
.Reverse()))
.Distinct()
.ToList();
return Ok(urls);
}
This will return response in the following format:
[
"/post/delete",
"/users/index/administration",
"/users/details/administration",
]
If you need more information, the IActionDescriptorCollectionProvider
has plenty of it.
.NET 5 AspNetCore catch-all route supersedes defined route
As it turns out, the behavior was due to the aspnetcore team introducing a change to the routing mechanism in 5.0 - the problematic behavior is actually by design.
See more here: https://github.com/dotnet/aspnetcore/issues/29594
ASP Core generate full paths for all endpoints
Paraphrasing your question, you have a branching request pipeline, calling .UseEndpoints
in multiple branches. But while the .Map
middleware adjusts Request.Path
& Request.PathBase
, end point routing is oblivious to this change.
I don't think this is supported in link generation. You should probably take a step back and re-evaluate if you really need to use .Map
at all. Or at least the preserveMatchedPathSegment = true
overload.
After a quick peek into the source code.
The .Map
methods each create a separate IApplicationBuilder
for that branched middleware pipeline.
Calling .UseRouting()
creates an IEndpointRouteBuilder
.
The IEndpointRouteBuilder
is then used by .UseEndpoints()
to define all the endpoints.
So here's a quick outline of what I'd attempt.
Write your own extension methods to replace .Map
& .UseEndpoints
and use those in your Startup
class.
Store (or combine) the new path base in IApplicationBuilder.Properties
.
Then in your .UseEndpoints()
callback, you can call the real one. Then create your own datasource with EndpointDataSource src = new CompositeEndpointDataSource(IEndpointRouteBuilder.DataSources)
. Combine that with the path base you stored earlier.
And populate all that into some other service object for later use.
Unless someone can point out a simpler way?
Related Topics
On Postback, How to Check Which Control Cause Postback in Page_Init Event
Visual Studio Debugging "Quick Watch" Tool and Lambda Expressions
Retrieving the Calling Method Name from Within a Method
How to Hide a Column (Gridview) But Still Access Its Value
How to Set Timer Resolution from C# to 1 Ms
Internet Explorer Protective Mode Setting and Zoom Levels
How to Get Current Page Url in MVC 3
Best Regular Expression for Email Validation in C#
How to Use the Linqpad Dump() Extension Method in Visual Studio
The Type Must Be a Reference Type in Order to Use It as Parameter 'T' in the Generic Type or Method
How to Add an Extra Button to the Window's Title Bar
Hashtable with Multidimensional Key in C#
Best Way to Access Com Objects from C#
Where's the Datetime 'Z' Format Specifier
The Maximum Number of Characters a Textbox Can Display
How to View Msil/Cil Generated by C# Compiler? Why Is It Called Assembly