The same web api controller name in 2 different areas, name spaces, and route prefixes cancel each other out with no warning or error

[mikewodarczyk]

My asp.net site is split into areas with different overrides of AreaRegistration, Each area is its own business context and could have different developers. I happened to chose a name for a web api controller eg. CustomerApiController (inheriting from ApiController) in one area (Shipping). This same web api controller name was used in another namespace (SalesOrder). They had separate [RoutePrefix("...")], existed in a different name space, linked to a different database under the covers, and meant something different.

The problem is that neither of them worked after I added the second one. The produced a "not found" when the client called into the APIs.

It looks like at the controller discovery phase, they are thrown out and not included in routing. I didn't
get any static analysis warnings from visual studio 2017 (latest version). I didn't see any exceptions or errors from the routing engine. It seems like this case should either be handled correctly by including names spaces or route info in the controller name descriptor, or it should fail loudly with some relevant exception,

[Jaans]

Ran into the same problem recently.

We have a large number of projects with API controllers that are in separate namespaces (heck some are even different assemblies). However, when any of the API controllers have the same name e.g. "CustomerController" the Web API doesn't recognise them anymore and we get a generic IIS 404 error, nuking out all controllers that have that name.

Having the same controller class name in different namespaces / assemblies is quite natural for us because each namespace is a different product team and by design may choose a similar name for that usage. Additionally we also dynamically drop in controller assemblies and don't always have control of the controller name, but can dictate the namespace.

Eg. The "Trades" product may need a "CustomerController" but the "Reporting" product may also need their own "CustomerController".

The fact that these controllers are in different namespaces or assemblies or different Routes (AttributeRouting) or even RoutePrefixes makes no difference to fixing the problem.

After a long debug session (which by the way was made much longer because the System.Web.Http.dll.pdb not available on a public symbol server - urgh!!!), I've traced it down to the internal System.Web.Http.Dispatcher.HttpControllerTypeCache class.

Specifically, the private InitializeCache() method is building a dictionary of lookups, grouped by controller name, but does so using the Type.Name property instead of using the Type.FullName property.
Refer line 61 of System.Web.Http.Dispatcher.HttpControllerTypeCache

What I cannot figure out is why this was done. Furthermore, the DefaultHttpControllerSelector.InitializeControllerInfoCache() method uses this dictionary of lookups and goes as far as to remove any "duplicate" controllers where there are more than one controller for a given name.

Oversight or by design?

As an experiment I grabbed the source and changed the implementation to use the FullName instead. Now, there are never any duplicates (because the namespace is now part of the name) and the issue doesn't happen. The controller selection and resolution continues to work as expected from our observations.

Despite so much of the ASP .NET WEB API bits being "plug-able", I cannot see a way to resolve this without re-inventing much of the wheel and so disconnecting from future ASP.NET WEB API fixes/changes.

I would really appreciate some feedback here from the development team as this is production scope stuff.

Is this a change for the framework? If not, is possible to add further plug-ability to the framework to allow for resolving these. Suggestions?

Thanks,
Jaans

[Jaans]

I since realised that my view above originates from using Attribute Routing, and when I consider the use case for the more traditional/conventional routes (E.g. {controller}/{action}/{parameter}) then it makes sense that only a controller name is available from the route to map to a controller in code. Therefore having two controllers with the same name regardless of namespace is a conflict for convention based routing.

In contrast, a route defined via a RouteAttribute has a clear link between the route and the controller and there is no ambiguity then as the attribute is applied to a single class.

I'll try to create a custom HttpControllerSelector that is intended for attribute routing only and that then takes into consideration the namespace.

[dougbu]

but does so using the Type.Name property instead of using the Type.FullName property

@Jaans this part is not entirely correct. DefaultHttpControllerSelector provides callers with an ICollection<Type> containing all controllers matching the requested name. I'm not sure why it internally organizes this with a nested Lookup<T> keyed on namespaces -- that detail isn't exposed to callers. In any case, "duplicates" are grouped together and not eliminated.

I suspect where controllers "are thrown out and not included in routing" is at a higher level and is likely specific to the routing approach.

[dougbu]

Further, DefaultHttpControllerSelector should spit out errors when a controller name is ambiguous. In the various cases which seem to "silently" ignore routes to controllers with matching names, are Exceptions thrown or errors logged?

[Jaans]

Thank you for your reply.

, are Exceptions thrown or errors logged?

No, no error or exception that points to the issue of ambiguous controller names. It is simply an IIS generic 404. This is because if there are duplicates, all of them are removed from the controllers to be select - refer to this section of code)

It is very much worth considering to but in a log/exception when this happens since it is actually quite difficult to determine the root cause as it presents a bit like a "silent fail".

Per my subsequent post, the current default implementation does now make sense to me given that the default controller selector is catering for both convention and attribute based route configurations.

Specifically, when using convention based routing (and not attribute based routing RouteAttribute), only the controller name is available from the URI request route, and therefore there can only be one matching controller in code, which explains the elimination of dups.

I have since bridged this particular issue with a custom IHttpControllerSelector but it would only work under attribute based routing, but since that is our scenario, it's OK and we would not be mixing the two kinds of routing in our projects.

[dougbu]

@Jaans thanks for helping me to understand your scenarios and where problems lie.

One way to address your main attribute routing concern would require re-architecting components such as the AttributeRoutingMapper. That's currently layered on the IHttpControllerSelector though the single controller limitation (as you note) shouldn't exist there (see

AspNetWebStack/src/System.Web.Http/Routing/AttributeRoutingMapper.cs

Line 106 in 7493846

IDictionary<string, HttpControllerDescriptor> controllerMap = controllerSelector.GetControllerMapping();

). Unfortunately I doubt this redesign would fly unless changes were focused almost-exclusively on AttributeRoutingMapper (which should be doable but may require duplicating much of DefaultHttpControllerSelector to get the controllers).

The other alternative would be to extend DefaultHttpControllerSelector to implement IHttpControllerSelector2 specifically for the AttributeRoutingMapper use case. The new interface would expose information about controllers without eliminating name-based duplicates.

If you have thoughts on solving this in ASP.NET Web API, I encourage you to pick an approach and submit a PR.

---

@rynowak let's talk offline sometime soon about why the current AttributeRoutingMapper over IHttpControllerSelector layering was chosen and whether we should take another look.

[dougbu]

@mikewodarczyk and @Jaans, I chatted with @rynowak and we agree the IHttpControllerSelector2 approach is the way to go. We're hoping this can be fixed in the next release because a bare 404 is a horrible way to handle this case.

[dougbu]

Note to self: Confirm MVC doesn't have a similar bug. The code at

AspNetWebStack/src/System.Web.Mvc/ControllerTypeCache.cs

Line 59 in 7493846

public ICollection<Type> GetControllerTypes(string controllerName, HashSet<string> namespaces)

looks similar.

[dougbu]

Marking as up-for-grabs in case someone gets to this issue before I tackle it.