ASP.NET MVC2 RC2 Areas Namespace Conflict

While converting an MVC1 app to MVC RC2 I created an Area and moved my existing controllers into said area. Resharper identified the “Namespace does not correspond to file location, should be: AAA.Areas.BBB.Controllers” as expected. A simple “Move declarations to namespace ‘AAA.Areas.BBB.Controllers’” was sufficient to alleviate the issue.

At this point I also realised I needed to change my default namespace for the project to “XXX.AAA” and hence the namespace of my controller needed to change to “XXX.AAA.Areas.BBB.Controllers”. No problem.

Tried to navigate to said controller and received http 404, “The Resource cannot be found”. Debugged and found the route was being registered via AreaRegistraion.RegisterArea but the controller constructor wasn’t being hit.

Fix 1 (The hard way) : context.MapRoute(name, url, defaults, namespaces) allows you to specify the controller’s namespace/s as outlined by haacked.

Fix 2 (The easy way): make sure the area registration uses the same namespace as the controller i.e. “XXX.AAA.Areas.BBB” instead of the original “AAA.Areas.BBB”.

Now everyone’s happy :)

ASP.Net MVC Pipeline – Part 1

This is Part 1 of a series of posts I hope to write exploring the Asp.Net MVC pipeline. It won’t be your typical “this is a view, this is a controller, right click add new item…” type series although it will start off fairly basic and I will attempt to simplify things where necessary.

I’ll also be exploring some best practice and testing concerns along the way.

Pipeline 101

When I talk about the pipeline, I’ll mostly be talking about the stuff that happens OUTSIDE of your views, models and controllers. You might be wondering why you would want to do that? Well Asp.Net provides quite an array of conventions that can be overridden by the developer. Ever wondered how on earth you can specify an action to receive a populated instance of one of your domain classes? Well these “extensibility points” points allow you to change this type of behaviour.

Our First Request

Like I said, I was going to simplify things :) Anyone who’s had a cursory glance at Asp.Net MVC should be able to understand what’s going on here. I won’t go into great detail for each step but there are a few things I’d like to point out.

If we look at the controller action definition, it is simply:

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

Other than the method name, nowhere does it specify what view to actually use. We can verify this with the following test which will fail in this scenario

[TestMethod] public void Index_Returns_ViewName_Index() { AccountController ac = new AccountController(); ViewResult viewResult = ac.Index() as ViewResult; Assert.AreEqual(viewResult.ViewName, "Index"); }

So how does the pipeline know to render the view at “~/Views/Account/Index.aspx”? Well that’s a convention of the default MVC pipeline that we can extend and control as we see fit.

This also means that the controller action and view are not tightly bound too each other. The action cares not what happens with the action result it returns nor does the view care which action its data comes from. In this way we can even replace entire parts of the pipeline e.g alternate view engines.

This separation really sets MVC apart from webforms and allows for much easier testing. Despite their appearances controllers and views can still “Do Bad Things” like make calls to Response.Redirect(…) etc. Generally from upon though :)

In Part 2 we’ll be examining probably the easiest way to manipulate the pipeline: Routes!

Let them have their cake

I have been reading a lot of blogs and forums lately with heated discussions on why you should/shouldn't use Asp.Net MVC over Asp.Net Webforms. Starting to get a little tired of it all now as it's turned into the same sort of debates that happened when RoR hit the market. Although it's fun to note that (for once) this discussion can't devolve into the obligatory microsoft == CRAP shit fight.

I'm as used to rejection as the next IT nerd, so guys if people don't want to use your beloved MVC, get over it! MVC will grow and prosper regardless of whether EVERY Asp.Net Webforms developer starts using it. Let's just concentrate on making MVC a better product instead of trying to convince the naysayers to convert.

I must admit i was wary of things like Tag Soup, dealing with raw HTML/HTTP, etc as I've mostly done Asp.Net Webforms with a little Perl and RoR on the side. But the difficulty in utilizing these concepts is nothing compared to dealing with Page Lifecycle, View State, obfuscated element ids, etc, etc, etc.

Html.ActionLink gotcha

For some reason I keep getting tripped up by the following sort of code: <br /><%=Html.ActionLink("Back to List", "Details", "ActionRule", new { id = Model.ActionRuleId } )%><br /> Seems simple enough but you end up with a link like : http://localhost:5825/ActionRule/Details?Length=10 Easy fix is to add a null parameter to the end of the list. Why? Well the compiler treats the first call as: System.Web.Mvc.Html.LinkExtensions.ActionLink(this System.Web.Mvc.HtmlHelper htmlHelper, string linkText, string actionName, object routeValues, object htmlAttributes) Obviously the parameters are resolved incorrectly as there is no method signature such as: System.Web.Mvc.Html.LinkExtensions.ActionLink(this System.Web.Mvc.HtmlHelper, string, string, string, object) I really should write an extension method to cover this (fairly common for me) scenario. Who cares you say? Well to this point it seems that this is the only situation using ASP.Net MVC where I've had to add a null parameter on the end of a call to get the desired result. Not saying it's a bug...just interesting none the less.

The view 'Logon' or its master could not be found frustration

Ran into this one again today:

The view 'Logon' or its master could not be found. The following locations were searched:
~/Views/Account/Logon.aspx
~/Views/Account/Logon.ascx
~/Views/Shared/Logon.aspx
~/Views/Shared/Logon.ascx

of course all the files were present because it was working 5 minutes ago (and the 2 weeks or so before that).

I had been using the ASP.Net MVC source project to debug a few things, but reverted to the GAC dll before checking in so that the other devs didn't end up with some phantom project reference. Hence I thought I had not reverted my web.config (and ~/Views/web.config) changes properly.

Anyway half an hour later and a lot of head scratching later I thought I'd see if setting the System.Web.MVC reference to "Copy Local =True" would make any difference
...
it did.

End of story.

HTML Engine Automatic Tag Expanding

Well this one had me stumped for a little while... I'm using the JQuery UI library for an ASP.NET (MVC) project. I was trying something quickly using FireBug I grabbed this piece of markup and pasted it into my .aspx page:

lt span class="ui-icon ui-icon-info" / gt
Hey! Sample

Easy i thought. I was expecting some CSS conflicts so it was no surprise that my aspx version didn't look the same as the example.html version. But for the life of me couldn't work out which attribute/element combinations were different. They looked identical, they actual CSS was identical.

After much hair pulling I discovered a mysterious closing span tag that wasn't present in my pasted code??? Seems most HTML rendering engines (IE, FF, Chrome) don't like to output inline closing tags for elements that should obviously have content e.g . Unfortunately for me, instead of converting:

 span /  ...

to:

...

they decide to "fill out" the element within its parent, such that:

...

and hence destroyed the CSS rules :(

Examing the network request/response in Firebug reveals that the HTML that comes down from the server is in fact the same as the .aspx file.

Note to self: to blindly copy/paste example code even when it really should work :)

Edit: I use Syntax Highlighter to format my code, but again the HTML engines seems to insist on messing up my inline lt span / gt tags for this post, grrr....

Don't name your View "View"

but if you must don't try to use code like this: public class PostController : Controller { public ActionResult View() { ViewData["Title"] = "View Post"; return View(); } } Obviously you'll just end up with a StackOverflowException. ActionName attribute to the rescue! [ActionName("View")] public ActionResult Show() { ViewData["Title"] = "View Post"; return View(); } It's strange what working in a different environment or with different technology can lead you to make the most simple mistakes :)