Locate view bug in MVC3 RC

Hi,

I have a controller in an area (/Areas/Admin/Controller/JackpotController.cs) with the following code

public ActionResult Index()
        {
            return View();
        }

I have a Razor view here: /Areas/Admin/Views/Jackpot/Index.cshtml.

I have a Web Forms view (which is not in an area) here: /Views/Jackpot/Index.aspx.

The controller returns the Web forms view and not the Razor view!

I removed both views to force this exception, which explains why the wrong view is returned:

The view 'Index' or its master was not found. The following locations were searched:
~/Areas/Admin/Views/Jackpot/Index.aspx
~/Areas/Admin/Views/Jackpot/Index.ascx
~/Areas/Admin/Views/Shared/Index.aspx
~/Areas/Admin/Views/Shared/Index.ascx
~/Views/Jackpot/Index.aspx
~/Views/Jackpot/Index.ascx
~/Views/Shared/Index.aspx
~/Views/Shared/Index.ascx
~/Areas/Admin/Views/Jackpot/Index.cshtml
~/Areas/Admin/Views/Jackpot/Index.vbhtml
~/Areas/Admin/Views/Shared/Index.cshtml
~/Areas/Admin/Views/Shared/Index.vbhtml
~/Views/Jackpot/Index.cshtml
~/Views/Jackpot/Index.vbhtml
~/Views/Shared/Index.cshtml
~/Views/Shared/Index.vbhtml

As you can see, MVC incorrectly searches the root aspx views before the area cshtml views. Correct behavior should be to always search areas first, regardless of view engine.

/ Oskar

Re: Locate view bug in MVC3 RC

dillenmeister
As you can see, MVC incorrectly searches the root aspx views before the area cshtml views. Correct behavior should be to always search areas first, regardless of view engine.

If you see the MVC source you will find that MVC pick the top most view engine in the view engines stack then start matching the view. If no matching view is found then pick the next view engine and so on. I think this is much feasible that you select a view engine one by one and match it with your view rather then selecting all the regestered view engines only for area concern first and then selecting all the regestered view engines for all non-area concern.

For your particular case you can either prioritize razor view engine or use the IView overload of View method.

return View(new RazorView("~/Areas/SomeArea/Views/List/Index.cshtml"));

http://forums.asp.net/p/1593209/4041505.aspx

Re: Locate view bug in MVC3 RC

Thank you for explaining why it chooses the web forms engine before the razor one. I understand that it might have been easier to implement it like that. But you still haven't convinced me that this behavior is better.

I think it should first look in Areas, then the root and then Shared, like this:

Area
1. Web forms
2. Razor
3. ...
Non-area
1. Web forms
2. Razor
3. ...
Shared
1. Web forms
2. Razor
3. ...

But I might be missing something, so please describe a scenario where the current implementation (view engine by view engine) would be better then the order above.

Re: Locate view bug in MVC3 RC

Just remove the webForms view engine.

protected void Application_Start() {
            ViewEngines.Engines.RemoveAt(0);

Re: Locate view bug in MVC3 RC

dillenmeister

I think it should first look in Areas, then the root and then Shared, like this:

The order is view engines. You will get the expected behavior if you change the order of view engines using the code snippet I provided.

protected void Application_Start() {
            ViewEngines.Engines.Clear();
            ViewEngines.Engines.Add(new RazorViewEngine());
            ViewEngines.Engines.Add(new WebFormViewEngine());


            AreaRegistration.RegisterAllAreas();


            RegisterGlobalFilters(GlobalFilters.Filters);
            RegisterRoutes(RouteTable.Routes);
        }

Re: Locate view bug in MVC3 RC

Thanks! That is the best way for me to work around the problem.

May I ask if you think the current behavior (view engine by view engine) is better than what I suggested (area, non-area, shared)?

</div>

Re: Locate view bug in MVC3 RC

The current algorithm is better for most developers and better for the MVC framework maintainability. Most applications don't use more than one view engine. Some use 3 or more view engines. In reality this isn't a problem as you probably shouldn't have the same named view for different view engines.

Re: Locate view bug in MVC3 RC

The views will often be named the same regardless of view engine right (Index, Create, Details etc.)?

The problem was not that I had Index.aspx and Index.cshtml in the same view folder. I understand that it will pick Index.aspx first if I would do that. The problem was that I had Index.cshtml in an Area view folder and Index.aspx in the root view folder and MVC picks Index.aspx from the root even though the controller with return View("Index") was in the area.

If you do return View("Index") in /Areas/Admin/Controllers/HomeController.cs wouldn't it be more logical and intuitive if it used /Areas/Admin/Views/Home/Index.cshtml rather than /Views/Home/Index.aspx?

Sorry if I'm nagging, I'm just surprised that I'm the only one that thinks this is weird:)

</div>

Re: Locate view bug in MVC3 RC

dillenmeister

<div style="color:#000000;font-family:Verdana, Arial, Helvetica, sans-serif;font-size:12px;background-image:initial;background-attachment:initial;background-origin:initial;background-clip:initial;background-color:#ffffff;margin:8px;" mce_style="color:#000000;font-family:Verdana, Arial, Helvetica, sans-serif;font-size:12px;background-image:initial;background-attachment:initial;background-origin:initial;background-clip:initial;background-color:#ffffff;margin:8px;">
Sorry if I'm nagging, I'm just surprised that I'm the only one that thinks this is weird:)
</div>

No problem. It's unfortunate that the current design does not work in your particular scenario. However, you should understand that the concept of Areas is not something that is inherent to MVC as a whole. Rather (though i'm simplifying a bit), it's a convention that is implemented in the WebFormViewEngine (and RazorViewEngine in MVC 3).

The general contract for view engines in MVC is that there is a collection of them and when a view lookup occurs they are asked in turn to provide a view. The first one wins and any view engine after is not 'questioned'. It's up to the individual view engines to have any fallbacks, such as the Areas pattern fallback. There might exist view engines out there that don't implement areas at all.

Unfortunately we cannot change this contract at this point because that would likely result in breaking changes in existing applications. However, you can always implement you own IViewEngine that follows your preferred lookup patterns.

Re: Locate view bug in MVC3 RC

marcind
It's up to the individual view engines to have any fallbacks, such as the Areas pattern fallback. There might exist view engines out there that don't implement areas at all.

Thank you for taking the time clearing this up for me! I understand why it has to behave the way it does now.

Re: Locate view bug in MVC3 RC

Oskar, I've written a blog post that addresses your scenario. You can make things work intuitively by a single change in Global.asax (view engine registration). Read about Areas and multiple view engines.

Re: Locate view bug in MVC3 RC

Very good and informative blog post!

Quote from the blog post:

marcind
This technique should be helpful for those who want to transition their application from Aspx to Razor (or maybe between some other pair of view engines). However, once you are done with the transition you should probably stick to just having one view engine registered to avoid unnecessary searches in the other view engines.

Do you think the only reason to mix view engines is when transitioning between one to another? Is the best practice to have one view engine only? I can understand this for Razor and web forms, since they are very similar in how they work. But suppose you want to mix different view engines because one view engine solves a certain problem better than the other for some of the views? With the ability in MVC3 to easily choose view engine for each view, I can imagine people mixing view engines quite a bit which would make this a more common issue. Any thoughts on this?

Re: Locate view bug in MVC3 RC

There is a cost associated with having multiple view engines looking for files on disk, unquestionably. It's a decision you make as a developer what the potential benefits vs. costs are.

Re: Locate view bug in MVC3 RC

To add to what Brad said, it's a best practice (in any sort of development) to remove unused things from your application (be it code, resources, view engines) to keep it as simple and straigthforward as possible. But if you need something then you need it. Having multiple view engines will have a small initial perf hit, but should not have a signifficant impact throughout the whole life of your app domain. My comment was more about maintaining a clean application.

Re: Locate view bug in MVC3 RC

Marcin

That's interesting ... but it doesn't seem to work, unless I'm missing something.

When trying to find views that are not part of an area, you get an exception when using the area-specific view engines. Looking in the source at VirtualPathProviderEngine.GetPath(), if there is no area defined, the set of view locations is only made up of those in ViewLocationFormats ... and that's empty. So, GetPath() throws an exception.

Actually, the problem I had/have is slightly different. I do have a combination of Razor and WebForms as part of a migration ... with a preference for Razor. When looking for a view in an area (which is WebForms in part), it actually found a view of a matching name in the default non-area locations which was Razor (rather than the WebForms one I expected) ... but then found the master in the area in Razor (because I'm partially migrated). Result: a nasty mess and a mismatch of view and master!

The problem (if problem it is) seems to be that, even when an area is defined, GetPath() falls back to looking in the non-area locations as well. Seems to me that a similar mechanism to the one in controllers to prevent that fallback (perhaps selectively) would be nice. I don't see an easy way to override that, however.

Adrian

Re: Locate view bug in MVC3 RC

adrian pell

That's interesting ... but it doesn't seem to work, unless I'm missing something.

Sorry about that, I've fixed the code in my blog post.

adrian pell

Actually, the problem I had/have is slightly different. I do have a combination of Razor and WebForms as part of a migration ... with a preference for Razor. When looking for a view in an area (which is WebForms in part), it actually found a view of a matching name in the default non-area locations which was Razor (rather than the WebForms one I expected) ... but then found the master in the area in Razor (because I'm partially migrated). Result: a nasty mess and a mismatch of view and master!

The problem (if problem it is) seems to be that, even when an area is defined, GetPath() falls back to looking in the non-area locations as well. Seems to me that a similar mechanism to the one in controllers to prevent that fallback (perhaps selectively) would be nice. I don't see an easy way to override that, however.

I'm having a hard time understanding how to repro your issue. Could you post a list of the relevenat files that exist in your project, what kind of request you are making, and which ones get chosen by the system (and indicate how that differs from what you expect)?

Re: Locate view bug in MVC3 RC

marcind

Sorry about that, I've fixed the code in my blog post.

Cool - although I guess the presence of that non-existent file name would result in more failed lookups in the file system. Probably for every non-area view lookup.

marcind

I'm having a hard time understanding how to repro your issue. Could you post a list of the relevenat files that exist in your project, what kind of request you are making, and which ones get chosen by the system (and indicate how that differs from what you expect)?

Sorry - let me try again! Here's the rough filesystem layout ...

Views
... Admin [this is the area name]
... ... Home
... ... ... Index.aspx <--- this is the view I expect to render
... ... Shared
... ... ... _Site.cshtml
... ... ... Site.Master
... Home [this is the controller that is not in a view]
... ... Index.cshtml
... Shared
... ... _Site.cshtml

The view engines are configured (1) Razor (2) WebForms.

When I try to fetch the view for action Admin/Home/Index, here's what I think happens:

Razor view engine looks for Home/Index.cshtml. It tries in the Admin area (fails) then falls back to try in the non-area views, and here it finds Index.cshtml. Of course, this is actually the wrong view.
Now, Razor looks for the layout and finds _Site.cshtml in the Admin area (this is here because I'm gradually migrating)
Unfortunately, the Admin layout does not have some sections defined that the regular one does, so the view engine fails to render. It would have rendered the wrong thing anyway.

It seems to me that the fallback in GetPath() to look in the non-area view locations is the problem here. I suppose that makes sense when looking for masters and, perhaps, partials - but it seems wrong for the actual base view. I don't see a way to change the behavior however without a trick similar to yours.

FWIW, the solution you updated does work in this case, although as I said I'd be concerned about the extra file system accesses for the non-existent file (especialy since this is for views in my normal site, as opposed to the area). I just ran Process Monitor against that, and it does seem to do a bunch of lookups, although most of them are apparently for the compiled version of the non-existent page ... whcih doesn't exist either.

Adrian

Re: Locate view bug in MVC3 RC

BTW - although this particular problem is expressed in terms of two view engines, the same thing could happen in the case of a single view engine where the appropriate view is missing inside the area (not written yet, etc.) Rather than giving a rendering error (cannot find view), it could render the wrong thing (from the base, not the area) with potential for mis-matching layouts, models and who knows what else.

I know that avoiding duplicate names is best, but that's not always possible.

Adrian

Re: Locate view bug in MVC3 RC

I don't know if this worked for other people, but it didn't work for me. I just downloaded MVC3 RC2 yesterday. In this release, neither Razor, nor webforms engine scan Areas for views at all.

I have Area called "Admin" with AdminController inside of that area. I right clicked on the "Index" method of the controller and added an Index view. I made the following change in Global.asax.cs

protected void Application_Start()
{
    ViewEngines.Engines.Clear();
    ViewEngines.Engines.Add(new RazorViewEngine());
    ViewEngines.Engines.Add(new WebFormViewEngine());

AreaRegistration.RegisterAllAreas();

RegisterGlobalFilters(GlobalFilters.Filters);
RegisterRoutes(RouteTable.Routes);
}

When I load Admin area in the browser, it seems that both engines are only searching the root view folder and completely ignoring the areas. Basicaly, it just assumes that Admin was just another controller added in the root and doesn't search anywhere else. See below.

The view 'Index' or its master was not found or no view engine supports the searched locations. The following locations were searched:
~/Views/Admin/Index.cshtml
~/Views/Admin/Index.vbhtml
~/Views/Shared/Index.cshtml
~/Views/Shared/Index.vbhtml
~/Views/Admin/Index.aspx
~/Views/Admin/Index.ascx
~/Views/Shared/Index.aspx
~/Views/Shared/Index.ascx

What am I missing here?

Re: Locate view bug in MVC3 RC

mlofny
The view 'Index' or its master was not found or no view engine supports the searched locations. The following locations were searched:
~/Views/Admin/Index.cshtml
~/Views/Admin/Index.vbhtml
~/Views/Shared/Index.cshtml
~/Views/Shared/Index.vbhtml
~/Views/Admin/Index.aspx
~/Views/Admin/Index.ascx
~/Views/Shared/Index.aspx
~/Views/Shared/Index.ascx

This is showing that your Area route is not matched. Try this

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