Question

I have a basic MVC 2 (RC2) site with one base-level controller (“Home”), and one area (“Admin”) with one controller (“Abstract”). When i call http://website/Abstract – the Abstract controller in the Admin area gets called even though i haven’t specified the Area in the URL. To make matters worse – it doesn’t seem to know it’s under Admin because it can’t find the associated view and just returns:

The view 'Index' or its master was not found. The following locations were searched:
~/Views/Abstract/Index.aspx
~/Views/Abstract/Index.ascx
~/Views/Shared/Index.aspx
~/Views/Shared/Index.ascx

Am i doing something wrong? Is this a bug? A feature?

Answer 1

My friend and I were experiencing the same issue with Areas in ASP.NET MVC 2. We found a “hack” that, so far, seems to be working. For the tl;dr version, see the bottom of this answer.

You’ve probably got something similar to the following in your “Admin” area’s “AdminAreaRegistration.cs” class:

// Web/Areas/Admin/AdminAreaRegistration.cs

public override void RegisterArea(AreaRegistrationContext context) {
    context.MapRoute(
        "Admin_default",
        "Admin/{controller}/{action}/{id}",
        new { action = "Index", id = UrlParameter.Optional }
    );
}

Thus, it should make sense that when you make a request for “http://website/Abstract“, the “Admin_default” route does not match the request. So, by design, the MVC framework attempts to match the request against any other defined routes. If you used the MVC tooling within Visual Studio to create your web project, you’ll have a “Default” route defined in your “Global.asax” file (at the root of your web project). It should look similar to this:

// Web/Global.asax.cs

public static void RegisterRoutes(RouteCollection routes) {
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    routes.MapRoute(
        "Default",
        "{controller}/{action}/{id}",
        new {controller = "Home", action = "Index", id = UrlParameter.Optional}
    );
}

The “Default” route succeeds in matching the request for “http://website/Abstract“, with “controller” = “Abstract”, “action” = “Index” (default value), and “id” = UrlParameter.Optional (default value). This is the correct, and intended, behavior… so far.

Now, the MVC framework will attempt to load the “Abstract” Controller. By design, MVC will search for a class called “AbstractController” that extends “Controller” anywhere within the web project’s file/namespace hierarchy. It is important to note that a Controller’s file location and namespace do not affect MVC’s ability to find it; in other words, just because you’ve placed the “AbstractController” within a folder called “Areas\Admin\Controllers” and changed the namespace to be “Web.Areas.Admin.Controllers” instead of, say, “Web.Controllers”, doesn’t mean that MVC won’t use it.

When MVC executes the “Index” action in “AbstractController” which, most likely, just returns “View()”, then MVC gets confused because it doesn’t know where to find the “Index” view. Because MVC has matched a non-area route (the “Default” route in Global.asax), it thinks the matching view should be located in non-area view folders. Thus you get the familiar error message:

The view 'Index' or its master was not found. The following locations were searched:
~/Views/Abstract/Index.aspx
~/Views/Abstract/Index.ascx
~/Views/Shared/Index.aspx
~/Views/Shared/Index.ascx

We, just as you, didn’t want requests for “http://website/Abstract” to resolve to “Admin” area’s “AbstractController”; only “http://website/Admin/Abstract” should work. I can’t think of why anyone would want this behavior.

A simple solution is to delete the “Default” route in Global.asax, but this will break any regular non-area Controllers/Views. This is probably not an option for most people…

So, we thought we could restrict the set of Controllers that MVC would use for requests matched by the “Default” route in Global.asax:

// Web/Global.asax.cs

public static void RegisterRoutes(RouteCollection routes) {
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    routes.MapRoute(
        "Default",
        "{controller}/{action}/{id}",
        new {controller = "Home", action = "Index", id = UrlParameter.Optional},
        new[] {"Web.Controllers"} // Added this line
    );
}

Nope. A request for “http://website/Abstract” will still use “AbstractController” within the “Admin” area, even though the “AbstractController”‘s namespace is “Web.Areas.Admin.Controllers” and (clearly) not “Web.Controllers”. This is thoroughly confusing; it seems like this white-list has no dicernable affect on MVC’s Controller resolution.

– tl;dr answer starts here –

After some hacking, we figured out how to force MVC to only use Controllers within the white-listed namespace(s).

// Web/Global.asax.cs

public static void RegisterRoutes(RouteCollection routes) {
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    routes.MapRoute(
        "Default",
        "{controller}/{action}/{id}",
        new {controller = "Home", action = "Index", id = UrlParameter.Optional},
        new[] {"Web.Controllers"}
    ).DataTokens["UseNamespaceFallback"] = false; // Added this line
}

Set the “UseNamespaceFallback” key of the DataTokens dictionary on the “Default” route to false. Now, when we make a request for “http://website/Abstract“, the “Default” route will still be matched (this is valid behavior!) but MVC will not use any Controller that is not within the defined namespace(s); in this case, only Controllers within the “Web.Controllers” namespace are valid. Finally, this is the functionality we were looking for! We can’t figure out why this isn’t the default behavior. Weird, huh?

Hope this helps.