Blazor added an MVC app on IIS has multiple matching endpoints issue

Viewed 48

I am stuck with this weird issue and have been unsuccessful at finding a solution.

You can view another question I asked for a detailed background on the issue (as well as some of the code): Adding Blazor to existing MVC web project, "Request matched multiple endpoints" to /_Host

A short background is this: I am working on a proof of concept for a MVC app that we want to slowly migrate to Blazor. I have added blazor to the application based on several online tutorials. I have a working blazor component in a razor page. But when I try to have a blazor page I get an error when navigating to it:

2022-09-12 12:17:27.8448||ERROR|Microsoft.AspNetCore.Server.IIS.Core.IISHttpServer|Connection ID "18014398511092596900", Request ID "800000a7-0000-fa00-b63f-84710c7967bb": An unhandled exception was thrown by the application. Microsoft.AspNetCore.Routing.Matching.AmbiguousMatchException: The request matched multiple endpoints. Matches: 

/_Host
/_Host
   at Microsoft.AspNetCore.Routing.Matching.DefaultEndpointSelector.ReportAmbiguity(CandidateState[] candidateState)
   at Microsoft.AspNetCore.Routing.Matching.DefaultEndpointSelector.ProcessFinalCandidates(HttpContext httpContext, CandidateState[] candidateState)
   at Microsoft.AspNetCore.Routing.Matching.DefaultEndpointSelector.Select(HttpContext httpContext, CandidateState[] candidateState)
   at Microsoft.AspNetCore.Routing.Matching.DefaultEndpointSelector.SelectAsync(HttpContext httpContext, CandidateSet candidateSet)
   at Microsoft.AspNetCore.Routing.Matching.DfaMatcher.SelectEndpointWithPoliciesAsync(HttpContext httpContext, IEndpointSelectorPolicy[] policies, CandidateSet candidateSet)
   at Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware.<Invoke>g__AwaitMatch|8_1(EndpointRoutingMiddleware middleware, HttpContext httpContext, Task matchTask)
   at Microsoft.AspNetCore.Session.SessionMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Session.SessionMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.ResponseCompression.ResponseCompressionMiddleware.InvokeCore(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)
   at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.HandleException(HttpContext context, ExceptionDispatchInfo edi)
   at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)
   at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContextOfT`1.ProcessRequestAsync()|url: http://10.186.34.90/test|action: Error

If you look at my previous question you'll see that I tried deploying this exact same application to another server and the issue was not present. So I concluded this must have something to do with IIS.

Since then I have been comparing the site's settings in IIS and haven't found anything I could change to fix it.

I then created a small application with the same basic Page/View/Controller layout as the application I am working on. Just in the default application that VS creates when you select an ASP.Net core MVC app template. I added blazor the same way as I did in the main application and this application doesn't have an issue on either the trouble server or the server where the main app works.

Needless to say I am now very lost and confused about whether this is an IIS issue or an application issue. It seems to be a combination but I am out of ideas.

If anyone can please offer suggestions as to things to look at I would greatly appreciate it. I am more than happy to give any other info you request.

1 Answers

After many hours of looking at IIS and making various code changes I was able to arrive at a solution.

It turns out .Net 6.0.1 has a bug where this happens. The reason the site was working correctly on other servers had nothing to do with IIS but instead they had an updated version of .Net where the bug was no longer present.

After updating to the latest version of the .Net Hosting Bundle (currently 6.0.9) the problem was resolved.

Related