November Happy Hour will be moved to Thursday December 5th.

AI OnAI Off

7.1 issue with regular MVC controller named HomeController

Vote:
 

Since upgrading to 7.1, any "regular" (non EPiServer derived) controller named "HomeController" fails to get resolved.  Instead, the 'EPiServer.Shell.UI.Controllers.EPiHomeController' controller is attempted... and it fails with the following:

 

No parameterless constructor defined for this object. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.           
Exception Details: System.MissingMethodException: No parameterless constructor defined for this object.
Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[MissingMethodException: No parameterless constructor defined for this object.]
   System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck) +0
   System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark) +113
   System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark) +232
   System.Activator.CreateInstance(Type type, Boolean nonPublic) +83
   System.Activator.CreateInstance(Type type) +6
   System.Web.Mvc.DefaultControllerActivator.Create(RequestContext requestContext, Type controllerType) +55

[InvalidOperationException: An error occurred when trying to create a controller of type 'EPiServer.Shell.UI.Controllers.EPiHomeController'. Make sure that the controller has a parameterless public constructor.]
   System.Web.Mvc.DefaultControllerActivator.Create(RequestContext requestContext, Type controllerType) +179
   System.Web.Mvc.DefaultControllerFactory.GetControllerInstance(RequestContext requestContext, Type controllerType) +80
   System.Web.Mvc.DefaultControllerFactory.CreateController(RequestContext requestContext, String controllerName) +74
   System.Web.Mvc.MvcHandler.ProcessRequestInit(HttpContextBase httpContext, IController& controller, IControllerFactory& factory) +197
   System.Web.Mvc.MvcHandler.BeginProcessRequest(HttpContextBase httpContext, AsyncCallback callback, Object state) +49
   System.Web.Mvc.MvcHandler.BeginProcessRequest(HttpContext httpContext, AsyncCallback callback, Object state) +50
   System.Web.Mvc.MvcHandler.System.Web.IHttpAsyncHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData) +16
   System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +301
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +155
#73006
Jul 03, 2013 20:57
Stefan Torstensson
Stefan Torstensson
Vote:
 

First a quick check. Which versions of EPiServer.Shell.UI.dll and EPiServer.Cms.Shell.UI.dll do you have in the modulesbin folder of the site?

What path are you requesting? The idea is that the EPiServer controllers should be restricted to the ui paths.

If you browse to <your ui path>/shell/debug/routes you can see the configured routes and maybe figure out what's matching your request.

#73014
Jul 04, 2013 10:33
Vote:
 

2.1.82.0 - EPiServer.CMS.Shell.UI

2.1.90.0 - EPiServer.Shell.UI

 

This seems to happen when I request any path that is mapped to a "HomeController".  I have verified my route is "hit", because when I adjust my route to point at a different controller than "HomeController", the alternate controller loads.  For instance, I have the following route:

 

           

 

var defaultHome = routes.MapRoute(

                name:

 

"DefaultHome",

                url:

 

"Home/{action}/{id}",

                defaults:

 

new { controller = "Home", action = "Index", id = UrlParameter.Optional },

                namespaces:

 

new[] { "Mosaic.Controllers" }

            );

            defaultHome.DataTokens[

 

"area"] = "";

            defaultHome.DataTokens[

 

"UseNamespaceFallback"] = false;

 

If I run the version above, requesting mysite/Home I get the error in my original post.  However, if I modify it to:

 

 

           

 

 

 

var defaultHome = routes.MapRoute(

 

                name:

 

 

 

"DefaultHome",

 

                url:

 

 

 

"Home/{action}/{id}",

 

                defaults:

 

 

 

new { controller = "Account", action = "Index", id = UrlParameter.Optional },

 

                namespaces:

 

 

 

new[] { "Mosaic.Controllers" }

 

            );

 

            defaultHome.DataTokens[

 

 

 

"area"] = "";

 

            defaultHome.DataTokens[

 

 

 

"UseNamespaceFallback"] = false;

 

Then the request for mysite/Home works.  This same issue happens for all of my Areas, but so far, *only* for those routes mapped to a HomeController.  It's like my namespace arguments are entirely ignored, and if EPiServer finds that the controller requested is "Home", then it automatically tries to use EPiHomeController.

I'm not sure if the issue is in

ControllerTypeControllerFactory.GetControllerType

in EPiServer.Web.MVC?  It's like the type coming back is always replaced with EPiServer's controller?

 

 

#73065
Jul 04, 2013 22:52
Chris Sharp
Chris Sharp
Vote:
 

Do you have patch 3 installed? There was a bug when using certain controller names:

97346 - Some URL segements for pages such as "About" does not work because of name collisions with Controllers

http://world.episerver.com/Articles/Items/EPiServer-7---Patch-3/

#73070
Jul 05, 2013 5:35
Vote:
 

This does seem to be the exact behavior I'm seeing, but I just updated from the NuGet feed this week.  When I visit the NuGet package manager it shows that I have the latest versions of EPiServer.CMS.Core and EPiServer.Framework (althouth the description of each does not show the actual patch #). 

 

Is there a means I can verify the patch # based on dll versions? 

#73107
Edited, Jul 05, 2013 14:44
Chris Sharp
Chris Sharp
Vote:
 

If you've updated to a patch within the last week, you should have patch 3. The patch 3 DLLs versions end with .16 (compared with .8 for patch 2 and .4 (or .3) for patch 1).

#73109
Jul 05, 2013 15:17
Vote:
 

Yeah, both dlls end in .16.

#73110
Jul 05, 2013 15:35
Vote:
 

I ended up having to rename my HomeController(s) to HomeInternalController and explicitly map my routes to "HomeInternal", rather than "Home".  Any time my routes mapped a route to a controller name "Home", EPiServer tries to call the EPiHomeController.

 

For now, my code is "working", but I'm not really happy with this fix.

#73149
Jul 08, 2013 16:11
Stefan Torstensson
Stefan Torstensson
Vote:
 

This seems to be an issue introduced with one of the patches. I've managed to reproduce it with patch 3, but as far as I can tell it doesn't happen on an unpatched system.

I've filed a bug report for it.

 

#73177
Jul 09, 2013 15:11
This thread is locked and should be used for reference only. Please use the Episerver CMS 7 and earlier versions forum to open new discussions.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.