Feather View path routing fails if namespace for controller is using custom namespace
I had an existing MVC widget that was working fine until I enabled feather. After doing so I get an error like this:
Type : System.InvalidOperationException, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089Message : The view 'Index' or its master was not found or no view engine supports the searched locations. The following locations were searched:~/Views/Custom/Index.aspx~/Views/Custom/Index.ascx~/Views/Shared/Index.aspx~/Views/Shared/Index.ascx~/Views/Custom/Index.cshtml~/Views/Custom/Index.vbhtml~/Views/Shared/Index.cshtml~/Views/Shared/Index.vbhtmlSource : System.Web.MvcHelp link : Data : System.Collections.ListDictionaryInternalTargetSite : System.Web.Mvc.ViewEngineResult FindView(System.Web.Mvc.ControllerContext)HResult : -2146233079Stack Trace : at System.Web.Mvc.ViewResult.FindView(ControllerContext context) at System.Web.Mvc.ViewResultBase.ExecuteResult(ControllerContext context) at System.Web.Mvc.ControllerActionInvoker.InvokeActionResult(ControllerContext controllerContext, ActionResult actionResult) at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilterRecursive(IList`1 filters, Int32 filterIndex, ResultExecutingContext preContext, ControllerContext controllerContext, ActionResult actionResult) at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilterRecursive(IList`1 filters, Int32 filterIndex, ResultExecutingContext preContext, ControllerContext controllerContext, ActionResult actionResult) at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilterRecursive(IList`1 filters, Int32 filterIndex, ResultExecutingContext preContext, ControllerContext controllerContext, ActionResult actionResult) at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilterRecursive(IList`1 filters, Int32 filterIndex, ResultExecutingContext preContext, ControllerContext controllerContext, ActionResult actionResult) at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilterRecursive(IList`1 filters, Int32 filterIndex, ResultExecutingContext preContext, ControllerContext controllerContext, ActionResult actionResult) at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilterRecursive(IList`1 filters, Int32 filterIndex, ResultExecutingContext preContext, ControllerContext controllerContext, ActionResult actionResult) at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultWithFilters(ControllerContext controllerContext, IList`1 filters, ActionResult actionResult) at System.Web.Mvc.ControllerActionInvoker.InvokeAction(ControllerContext controllerContext, String actionName) at Telerik.Sitefinity.Mvc.ControllerWrapper.Execute() at Telerik.Sitefinity.Mvc.ControllerActionInvoker.ExecuteController(MvcProxyBase proxyControl) at Telerik.Sitefinity.Frontend.Mvc.Infrastructure.Routing.DynamicUrlParamActionInvoker.ExecuteController(MvcProxyBase proxyControl)I found it strange that it was searching ~/Views instead of ~/Mvc/Views. Support suggested I add the ControllerContainer attribute to the project, which I did but it did not fix the issue.
I was under the impression that this assembly directive ControllerContainer was only for external libraries that have controllers in them. This is not the case; the controller is in the Sitefinity project in the MVC folder...
However, I noticed that another of my MVC widgets was NOT broken... and loaded the views just fine (without the assembly directive).
After careful comparison I realized that while the widget that works is in the folder /Mvc/Controllers with a matching namespace of SitefinityWebApp.Mvc.Controllers, the one that is not working is in subfolder of controllers and therefore has an additional entry on the namespace like SitefinityWebApp.Mvc.Controllers.Custom.
This is the only difference I can find that explains it, and as you can see in the attached images, while the working controller has a whole list of AreaViewLocationFormats, the custom one only has four...
I tried to dig further to see where this AreaViewLocationFormats list is set but didn't have any luck.
Anybody have any additional insight as to why this is happening and how to fix it? changing the namespace of a widget that is already on the page is not a trivial task, so it would be great to learn that there is a workaround or fix...
let me know if you need more details to help troubleshoot the issue, thanks
Hello Josh,
If the controller is in a separate folder under the Controllers one, the views will not be found. Can you please try using an Area? We can continue the communication in the support thread you have opened.
Regards,
Nikola Zagorchev
Telerik