U4-5151 - Backoffice controllers collide on name even if different namespace

Created by Marc Stöcker 26 Jun 2014, 13:09:34 Updated by Warren Buckley (Personal) 23 Aug 2014, 19:38:11

Relates to: U4-5384

If multiple controllers (i.e. several packages) are named the same, they collide even though in different namespaces.

Multiple types were found that match the controller named 'SettingsApi'. This can happen if the route that services this request ('umbraco/backoffice/Analytics/SettingsApi//') found multiple controllers defined with the same name but differing namespaces, which is not supported. The request for 'SettingsApi' has found the following matching controllers: Analytics.Controllers.SettingsApiController SirTrevor.Settings.Controllers.SettingsApiController

Example: "SirTrevor for Umbraco" and "Analytics for Umbraco" crashing into each other...

If that can't be solved technically (respect namespace in routing), we need to at least be very explicit in documentation about this, IMHO. I tend to think that names like "Settings", "Config", etc. will be used by many packages.


Shannon Deminick 27 Jun 2014, 02:28:50

This is because the version of WebApi doesn't support this.

http://forums.asp.net/t/1773719.aspx?MapHttpRoute+same+named+controllers+different+namespaces http://forums.asp.net/p/1772699/4847780.aspx?Re+How+do+I+set+the+default+namespaces+in+MapHttpRoute+

We are using the Namespace trick when routing our controllers but it is not working. I'm assuming that's because we are not using a WebApi version that supports it. The next version is a major version and we cannot upgrade until v8 because it will be a breaking change.

The alternative is to create our own controller selector, something along these lines:


But that will require some investigation to see if that would introduce breaking changes.

Shannon Deminick 27 Jun 2014, 02:29:10

My advice is to name your controllers uniquely.

Shannon Deminick 27 Jun 2014, 03:00:58

It looks like even in the latest WebApi it doesn't support namespace/area lookups, have checked the source code.

So our only option is to implement a custom IHttpControllerSelector which I don't think will be a breaking change, if devs are implementing their own, then they will simply be replacing ours and will have this same problem - which if they want to fix it will need to inherit from our controller selector or implement the functionality.

Shannon Deminick 27 Jun 2014, 03:32:35

Fixed in rev: 8e7ed865f07dfeee939fb144f5ba4d1808f1328c

Warren Buckley (Personal) 27 Jun 2014, 07:41:41

So to be 100% clear this is now fixed and will be in 7.1.5 release? Or do we still need to to do the custom code as suggested in your blog post?

Anders Bjerner 27 Jun 2014, 07:44:30

At least for backwards compatibility I think it might be a good idea to manually prefix the WebAPI controllers.

Shannon Deminick 27 Jun 2014, 07:46:34

Warren - this fix is applied to 7.1.5, you don't need to do anything.

Anders - indeed, i still think people should be naming their controllers with some uniqueness to their packages.

Marc Stöcker 27 Jun 2014, 08:24:54

Yes, agree to Anders - we need to be backwards compatible within the 7.1 versions. I will prefix for now. Not pretty but ok. :)

Warren Buckley (Personal) 23 Aug 2014, 19:38:11

@Shandem ace that this has been fixed in 7.1.5 I would personally diasgree with naming controllers with a package name prefix.

SettingsApiController is a common name but being overly specific seems overkill but again just a personal preference/pet peeve, however great to know I don't need to prefix if I want to support older than 7.1.5 for now.

Cheers, Warren

Priority: Normal

Type: Bug

State: Fixed

Assignee: Shannon Deminick

Difficulty: Normal


Backwards Compatible: True

Fix Submitted:

Affected versions: 7.1.3, 7.1.4

Due in version: 7.1.5


Story Points: