humor, personal comments suggest edit

…and the feeling’s right.

phil-and-akumi If I can muster up the time and motivation, I like to try and post lighter more humorous fare on Fridays such as my recent RAS Syndrome post.

On this beautiful Friday day (is that redundant too?), I started off fresh out of ideas (and motivation) so I wasn’t planning on writing a blog post at all, until this was just handed to me.

Which Software Blogger Do Girls Like Better?

In this post, Nick Berardi takes a quick look around at the demographic information collected by Google’s new ad planner.

Consider for a moment, what this data represents. It is a huge database of information on surfing habits of perhaps nearly the entire Internet, collected via huge data centers consisting of unfathomable computing power (as well as power consumption). Not to mention the huge amount of data it represents and the incomprehensibly advanced statistical analysis algorithms that must be employed to properly sift this data.

Nick has all this power at his disposal to answer the pertinent question of the digital age.

Which geek blogger do chicks dig?

In the list, he compares bloggers such as Jeff Atwood (aka CodingHorror or is it CodingWhore, which might explain his results), Joel Spolsky (aka big red WTF guy), Scott Hanselman (aka Mr. “Writes About Hair”)… and then there’s me, the short end of the stick.

Now Jeff might have over 10 times the subscribers I have, Joel may be the most famous and respected of the bunch, and Scott may have the edge on me in terms of forefivehead, but guess who wins the only metric that matters?

That’s right, me suckas!

Eat that, CodingHorror!

Map Reduce FogCreek to FogWeak, Joel Spolsky!

Hanselminute is a minute too late, Scott Hanselman!

Of course, at this point is when my wife pinches her fingers together and holds them up to my temple and makes a loud hissing sound of air rushing out. After all, compared to the traffic level of these guys, my traffic is small enough that her periodic visits to my site would make a dent in the percentages.

And as my coworker Eilon points out, I’m celebrating what is effectively a made up score. “Hey everyone, I created this chart with this made up score, for which I have the highest one. I rock!” My retort is that his fascination with X-Box Achievement points is no different.

I guess I won’t quit my day job and become a male exotic dancer then. Carry on everyone.

Technorati Tags: humor,Friday,Ego mvc,, code comments suggest edit

When you create a new ASP.NET MVC project using our default templates, one of the things you might notice is that there is a web.config file within the Views directory. This file is there specifically to block direct access to a view.

Let’s look at the relevant sections.

For IIS 6 (and Cassini)

<add path="*.aspx" verb="*" 

For IIS 7

<add name="BlockViewHandler" path="*.aspx" verb="*" 
  preCondition="integratedMode" type="System.Web.HttpNotFoundHandler"/>

What these sections do is block all access to any file with the .aspx extension within the Views directory (or subdirectories). Note that access is blocked by mapping these file extensions to the HttpNotFoundHandler, so that a 404 error is returned when trying to access a view directly.

This works great if you are using all the ASP.NET MVC defaults, but what if you’re using an alternative view engine such as NHaml or NVelocity? It turns out you can directly request the view and see the code.

You’ll want to make sure to add extra lines within this web.config file with the appropriate file extensions. For example, if I were using NVelocity, I might add the following (in bold).

For IIS 6 (and Cassini)

<add path="*.aspx" verb="*" 
<add path="*.vm" verb="*" 

For IIS 7

<add name="BlockViewHandler" path="*.aspx" verb="*" 
  preCondition="integratedMode" type="System.Web.HttpNotFoundHandler"/>
<add name="BlockViewHandler" path="*.vm" verb="*" 
  preCondition="integratedMode" type="System.Web.HttpNotFoundHandler"/>

You might be wondering why we don’t block access to all files within the Views directory. Excellent question! In part, because the Views directory is a common place to put other static content such as images, pdfs, audio files, etc… and we decided not to prevent that option.

However, we’re open to suggestions. We do have a content directory in the default template. We could consider requiring putting static files in there or in another directory other than Views. I’m not sure how people would feel if they couldn’t put assets intended to support Views within the Viewsfolder.

Technorati Tags: aspnetmvc,security,view engines

code comments suggest edit

UPDATE: Updated the registry settings per James Curran’s comment. Thanks James!

One of the most useful registry hacks I use on a regular basis is one Robert McLaws wrote, the “ASP.NET 2.0 Web Server Here” Shell Extension. This shell extension adds a right click menu on any folder that will start WebDev.WebServer.exe (aka Cassini) pointing to that directory.


I recently had to repave my work machine and I couldn’t find the .reg file I created that would recreate this shell extension. When I brought up Robert’s page, I noticed that the settings he has are out of date for Visual Studio 2008.

Here is the updated registry settings for VS2008 (note, edit the registry at your own risk and this only has the works on my machine seal of approval).

32 bit (x86)

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shell\VS2008 WebServer]
@="ASP.NET Web Server Here"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shell\VS2008 WebServer\command]
@="C:\\Program Files\\Common Files\\microsoft shared\\DevServer
\\9.0\\Webdev.WebServer.exe /port:8080 /path:\"%1\""

64 bit (x64)

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shell\VS2008 WebServer]
@="ASP.NET Web Server Here"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shell\VS2008 WebServer\command]
@="C:\\Program Files (x86)\\Common Files\\microsoft shared\\DevServer
\\9.0\\Webdev.WebServer.exe /port:8080 /path:\"%1\""

For convenience, here is a zip file containing the reg files. The x64 one I tested on my machine. The x86 one I did not. If you installed Visual Studio into a non-standard directory, you might have to change the path within the registry file.

Technorati Tags: Tips,Registry,Visual Studio,Web Server

code comments suggest edit

I used to find the smart tag really annoying in Visual Studio because it is such a small target to hit with the mouse. Silly me, trying to expand a smart tag with a mouse.


When you highlight the tag with your mouse, it tells you that the keyboard combination of ALT + SHIFT + F10 will expand the menu.

What it doesn’t tell you is that there’s a two key combination that will also expand it. I learned this one from Karen Liu of the C# IDE team who also happens to have a blog post with a nice collection of other tips and tricks written last year.

Just hit the CTRL key plus the period key (CTRL + .)


I really like this approach when performing renames within Visual Studio because it’s totally contextual. Rather than starting with a rename refactoring, I can instead just start renaming something and the smart tag shows up and all I have to do is hit CTRL + . and then ENTER. Booyah!

Technorati Tags: Tips,Visual Studio,Shortcuts,Keyboard mvc,, code comments suggest edit

When approaching an extensibility model, I often find cases in which I want to merely tweak the existing behavior of the default implementation and wish I didn’t have to create a whole new specific type to do so.


Instead of creating a specific type, I tend to write a decorator class that implements the interface and takes in both the default instance of that interface and a delegate (specified using a lambda of course).

Let’s look at a quick example to make all this abstract talk more concrete. I’m playing around with the NVelocity View Engine for ASP.NET MVC from the MvcContrib project. Rather than have each controller specify the view engine, I’d really like to specify this in just one place.

I could take the time to setup a DI container, but I’m feeling lazy and this is just a simple prototype application so I planned to just implement the IControllerFactory interface and have it set the view engine after creating the controller.

For those not intimately acquainted with ASP.NET MVC, you can override how the framework instantiates controllers by implementing the IControllerFactory interface.

However, at this point, I realized I was creating these one-off controller factories all the time. What I really wanted was some way to decorate the existing controller factory with a bit of extra logic. What I did was write an extension method that allowed me to do the following in my Global.asax.cs file.

  (current, context, controllerName) => 
    var controller = current.CreateController(context, controllerName) 
      as Controller;
    if (controller != null) {
      controller.ViewEngine = new NVelocityViewFactory();
    return controller;

It’s a little funky looking, but what is happening here is that I am calling a new Decorate method and passing it a lambda. That lambda will be used to decorate or wrap the current controller factory and will get called when it is time to instantiate a Controller instance.

However, the lambda always receives the original controller factory so it can use it if needed. So in effect, the lambda wraps or decorates whatever the current controller factory happens to be.

In this case, all my lambda is doing is using the default controller to create the controller, and then it sets a property of that controller after the fact. However, if I wanted to, I could have had my lambda completely override creating the controller.

Here is the the code for the extension method to ControllerBuilder.

public static class ControllerFactoryExtensions {
  public static void Decorate(this ControllerBuilder builder
  ,Func<IControllerFactory, RequestContext, string, IController> decorator) {
    IControllerFactory current = builder.GetControllerFactory();
      new DelegatingControllerFactory(current, decorator));

As you can see, under the hood, I am actually replacing the current controller factory with a new one called DelegatingControllerFactory. But the implementation for this new factory is really simple. It simply calls a delegate that you supply. As far as the user of the Decorate method is concerned, this class doesn’t really exist.

internal class DelegatingControllerFactory : IControllerFactory {
  Func<IControllerFactory, RequestContext, string, IController> _factory;
  IControllerFactory _wrappedFactory;

  public DelegatingControllerFactory(IControllerFactory current
    , Func<IControllerFactory
    , RequestContext, string, IController> factoryDelegate) {
    if (factoryDelegate == null) {
      throw new ArgumentNullException("factoryDelegate");
    _wrappedFactory = current;
    _factory = factoryDelegate;

  IController IControllerFactory.CreateController(RequestContext context
  , string controllerName) {
      return _factory(_wrappedFactory, context, controllerName);

  void IControllerFactory.DisposeController(IController controller) {
    if (controller is IDisposable) {

With this in place, the next time I need to implement a one-off controller factory, I can simply decorate the current controller factory instead.

I’m starting to find myself using this pattern in a lot of places. The potential downside of this approach is that if someone else comes along who has to maintain it, they might find it difficult to understand if they’re not well acquainted with lambdas and delegates.

So it is a bit of a tradeoff between convenience for the code author and readability for the code reader.

Technorati Tags: aspnetmvc,controller factor,decorator,patterns

aspnet, aspnetmvc, code, patterns comments suggest edit

Or, as my recent inbox tells me, you’re not afraid to ask. ;)

A coworker recently asked for some good resources on getting up to speed on the Model View Controller (MVC) pattern. Around the same time, I received another email talking about how people are confused around the difference between MVC and the Model View Presenter (MVP) pattern.

mvcNo better opportunity to apply the DRY principle by answering some of these questions with a blog post.


The first place to start digging into the MVC pattern is to look at the Wikipedia entry. That’ll get you a nice brief summary of the pattern along with a list of resources.

In MVC, the Model represents the information (the data) of the application and the business rules used to manipulate the data, the View corresponds to elements of the user interface such as text, checkbox items, and so forth, and the Controller manages details involving the communication to the model of user actions such as keystrokes and mouse movements.

trygve If you’re really into it, you can go directly to the source and read the original papers from Trygve Reenskaug, the inventor of the pattern.

There you’ll learn from the original paper (pdf) that the initial name for the pattern was Thing-Model-View-Editor. The pattern was baked via a process of extracting, improving, and articulating existing command and control patterns used in the operation of Norwegian ship yards in order to streamline and improve operations.


That ought to get you going with the MVC pattern. Now onto Model View Presenter, which was a response to the inadequacies of the MVC pattern when applied to modern component based graphical user interfaces. In modern GUI systems, GUI components themselves handle user input such as mouse movements and clicks, rather than some central controller.

MVP was popularized by Taligent in this paper on the subject (pdf). More recently, Martin Fowler suggested retiring this pattern in favor of two variants: Supervising Controller and Passive View.

The Difference?

So what’s the diff between MVC and MVP? Using GitHub, here it is!


Sorry, bad joke but I couldn’t resist.

The two patterns are similar in that they both are concerned with separating concerns and they both contain Models and Views. Many consider the MVP pattern to simply be a variant of the MVC pattern. The key difference is in how both patterns solve the following question: Who handles the user input?

With MVC, it’s always the controller’s responsibility to handle mouse and keyboard events. With MVP, GUI components themselves initially handle the user’s input, but delegate to the interpretation of that input to the presenter. This has often been called “Twisting the Triad”, which refers to rotating the three elements of the MVC triangle and replacing the “C” with “P” in order to get MVP.

What About The Web?

If you were playing close attention, most of these articles focus on rich client applications. Applying these patterns to the web is a very different beast because of the stateless nature of the web.

ASP.NET WebForms, for example, attempts to emulate the rich client development paradigm via the use of ViewState. This is why many attempts to apply patterns to ASP.NET focus on the MVP pattern because the MVP pattern is more appropriate for a rich client application with GUI components. A while back I even tossed my Supervising Controller sample into the ring. The Patterns and Practices group at Microsoft ship an MVP Bundle for ASP.NET.

However, many web platforms embrace the stateless nature of the web and forego attempting to simulate a state-full rich client development environment. In such systems, a tweaked MVC pattern is more applicable.

This pattern has been adjusted for the Web for your application development enjoyment.

AFAIK, Struts, a Java web framework, is one of the first widely used web frameworks employing the MVC pattern, though most people now look at Rails as being the tipping point that really brought MVC to the web and popularized the MVC pattern for web applications.

ASP.NET MVC is a new (in development) alternative framework for ASP.NET developers that makes it easy for developers to follow the MVC pattern. This framework employs the MVC pattern rather than the MVP pattern because it does not attempt to emulate rich client development, and thus the MVC pattern is more appropriate.

More Reading

There’s a lot of good content out there that puts these patterns into historical and categorical perspective. Besides the links already mentioned in this paper, I recommend checking out…

humor comments suggest edit

Photo by lizerixt on stock.xchng Yesterday, I wrote a post that contained the phrase “BFFs Forever” in the title. Commenters were quick to point out the redundancy of “Forever” in the title.

Nice - BTW, your title is redundant, so your title reads “IronRuby and ASP.NET Best Friends Forever Forever”

Thanks! But I had made the very same point in that post.

And for those that don’t know, BFF is an acronym for Best Friends Forever. Yes, the “Forever” is redundant in the blog title, but it’s just how people use it.

Case in point, how often do you hear the phrase “PIN Number” which expands to “Personal Identification Number Number”. I started looking for other examples of such redundant acronyms and sure enough, there’s a term for them and a wikipedia article describing them.

RAS syndrome stands for “Redundant Acronym Syndrome syndrome,” and refers to the use of one of the words that make up an initialism or acronym as well as the abbreviation itself, thus in effect repeating that word. It is itself a humorous example of a redundant acronym.

And in case you didn’t notice, “RAS Syndrome” is itself humorously a RAS. The Wikipedia article points to other great examples.

  • ATM machine
  • HIV virus
  • ISBN number
  • CSS style sheets
  • Please RSVP
  • CNN Network

The article references another page with a collection of more redundant acronyms.

  • LAN network
  • DAT tape
  • RF frequency
  • UPC code

It’s not surprising that most of these come from the technology field as we tend to be very acronym happy and love our TLAs (Three Letter Acronyms).

So now it is my turn to coin a RAS. I am going to call it PCS syndrome which stands for “Premature Correction Syndrome syndrome.” This describes the condition in one is compelled to interject with a correction without having read through the rest of the contents, especially when the author offers an explanation for the seemingly erroneous item. ;)

I’m only teasing because PCS happens to me a lot. I find that the comments to many of my blog posts tend to focus on some irrelevant miniscule detail rather than the topic at hand. Which I’m not necessarily opposed to because that provides great fodder for future blog posts!

Technorati Tags: humor,acronyms,neology

humor comments suggest edit

Today’s Dilbert described one of the most challenging problems small consulting companies face. I’m sure Jon, Micah, and I remember experiencing this many times when trying to build and expand Veloc-IT (though Micah probably still gets the pleasure of dealing with this as he’s still chugging along).

Click the image to see the full size strip at

Interest Free

Technorati Tags: dilbert,funny,humor,consulting mvc, code comments suggest edit

UPDATE: I just posted the working demo here.

I wish I could have been there, but I was celebrating my son’s first birthday (which gives me an opening to gratuitously post a picture of the kid here).


I’m talking about Tech-Ed 2008 Orlando of course where John Lam presented a demo of IronRuby running on top of ASP.NET MVC.

This demo builds on prototype work I’ve done with defining ASP.NET MVC routes and views using IronRuby.

The final missing piece was defining controllers using IronRuby. Working with members of John’s team, Levi (a dev on the ASP.NET MVC team) made the necessary adjustments to get a prototype IronRuby controller working with ASP.NET MVC.

Disclaimer: This is all a very rough prototype that we’ve been doing in our spare time for fun. We just wanted to prove this could work at all.

Unfortunately, we can’t release the demo yet because it relies on unreleased ASP.NET MVC code. When we deploy our next CodePlex interim release of ASP.NET MVC, the demo that John provided should actually work. :)

And for those that don’t know, BFF is an acronym for Best Friends Forever. Yes, the “Forever” is redundant in the blog title, but it’s just how people use it. As an aside, I found out recently that a good buddy of mine in L.A. is actually working on the set of a new show tentatively titled “Paris Hilton’s My New BFF”, where contestants compete to become Paris Hilton’s new Best Friend.

Technorati Tags: aspnetmvc,ironruby mvc, code, comments suggest edit

My compadre Scott Hunter, another PM on the ASP.NET team, who happens to work on the Dynamic Data feature, recently put together an example of using ASP.NET MVC and Dynamic Data Web Forms together in the same application. Look for the link to on this Code Gallery page.

I’ve been working on a post detailing a couple different ways to integrate WebForms and MVC, but life has been really busy for me lately. Hopefully I’ll get that to you soon.

MysteryPersonIn the meanwhile, you can probably learn all you need to know by looking at this example.

By the way, Scott was recently featured on .NET Rocks. We need to get a better picture of him taken. That whole Smoking Man image has got to go.

Technorati Tags: aspnetmvc,dynamic data, mvc, code comments suggest edit

tacoma_narrows The design is never right the first time. Nor is it usually right the second time. This is one of those key lessons you learn over time building real software, and is the source of one of the chief complaints leveled at the Waterfall methodology for building software, which puts heavy emphasis on getting the design right up front.

We have to define “right” in this case. If by “right” you mean perfect, then I don’t think the design is ever right, as I’ve argued in the past that there is no perfect design.

Recently, this lesson was driven home as my feature team (ASP.NET MVC) were hashing out some tricky design issues. Many times, we find ourselves in a tight spot in which we have two different audiences demanding a different approach to a design problem. The tough part is that the solutions we come up with inevitable satisfy one camp at the expense of the other.

Let me be clear, it’s not our goal and intention to try and satisfy everyone as that is a sure means to satisfying nobody. As Bill Cosby once said…

I don’t know the key to success, but the key to failure is to trying to please everybody.

At the same time, I also think it’s a copout to simply give up immediately when a thorny design problem comes up with two disagreeing camps. It’s worth a good faith effort to try and gather ideas you haven’t considered before and see if you can’t just solve the problem in a manner that both camps are happy with. Or at least in a manner that one camp is happy, and the other is merely less happy.

An illustration of this point happened recently at work. After many iterations, I sent out our design meeting notes internally with our solution to a particular issue. ScottGu noticed the write-up and had some questions about the design (questions like WTF?) and called me and Eilon (the lead dev) into his office for a “short” meeting to discuss these recent design changes.

I made sure to call my wife before the meeting to let her know I would be late for dinner. Once we get a talking about MVC, I know it won’t be short. We spent two hours hashing out the design, going over options, shooting them down, trying out other ideas, and so on.

At some point, Scott proposed something my team had rejected earlier due to a major flaw. However this time, as he was proposing the idea, it suddenly occurred to me that there were two different ways to implement this idea. The one we thought of wouldn’t work, but a slight adjustment to the idea, the very one Scott was proposing, would make it workable.

Eilon and I left the meeting happy with the improved design, but now concerned with the fact that we had already implemented another solution, had a bunch of unit tests and automated web functional tests. Not to mention having to deal with explaining it to the team and getting buy in so close to our release deadline.

So we did the cowboy thing (which I generally don’t recommend) and decided instead of telling the rest of the team about it, we’d follow the old maxim: “Show, don’t tell”. So that night, we went and coded the whole implementation, updated all the unit and web tests, and had something to demo in the morning rather than talk about. Since we had updated all the tests, QA was much more amenable to signing off on making this change so close to the deadline.

In retrospect, the part that causes me pain in the missed opportunities sense was just how tantalizingly close we were to having implemented this very idea from the beginning. All that time spent prototyping, app building, etc… we could have saved by getting it right the first time.

But that’s the way design goes. Sometimes, you are so close to a great solution that if the wind blows a certain way, you’ll hit upon it, but if it blows another way, you dismiss your line of thought and move onto other plans. Try as you might, it is very difficult to get the design just right the very first time all of the time.

Luckily for us, our team had the agility to respond to a better design. Our suite of unit and integration tests gave us confidence that the changes we were making were not breaking the framework in other areas. To me, this is a real testament to the benefits of applying lean and agile principles in software development, as well as the benefits of having good unit test coverage.

Tags: design , Software Development, mvc, code comments suggest edit

I updated the template to have the correct assembly references so it should work now out of the box. Sorry about that.

northwindA while ago Scott Hanselman linked to my Northwind sample which itself was spawned from an initial sample that Brad Abrams wrote.

As I like to say (to anyone who will listen)

There ain’t no party like a Northwind Party

So I went and updated my sample to work well with the recently released ASP.NET MVC Preview 3Beta.

Download it here. comments suggest edit

A while back I wrote a sample that demonstrated how to use Routing with WebForms.

If you missed it, you can download the code here

With the recent announcement that Routing will be included with .NET 3.5 SP1, you can see why I wanted to put that demo together.

I have since updated that sample to work with the versions of Routing that comes with the April CodePlex build of MVC. This should also work with the SP1 Beta. I’ll verify that when I get a moment.

As part of this update, I added a new feature which allows applying a simple substitution. For example, suppose you want URLs such as /forms/whatever to route to a physical file /forms/whatever.aspx. You can do the following:


One mistake a lot of people make when looking at URL Routing is to think of it as URL Rewriting. The difference is subtle, but important. There is no URL rewriting going on with Routing.

What happens here is when an incoming request URL matches this route (aka the URL pattern on the left), the WebFormRouteHandler will instantiate the physical ASPX Page specified in the virtual path on the right and use that http handler to handle the request (Recall that the Page class implements the IHttpHandler interface). As far as the page is concerned, the URL is /forms/whatever/. For example, this means that the URL rendered by your form will match the current URL, unlike what typically happens with URL rewriting.

This is why the above won’t work if you try to map a route to a virtual path that contains a query string:


The reason the above route won’t work is that the virtual path on the right isn’t valid. The path needs to specify a page we can instantiate, not a request for an URL.

To save you from having to visit the previous post, here is a link to download the code

Technorati Tags: routing,aspnetmvc, mvc, code comments suggest edit

The news is out, the beta for the Visual Studio 2008 and the .NET Framework 3.5 Service Pack has been released. As it relates to ASP.NET MVC, there are two important points to notice about the SP1 release:

  • ASP.NET MVC is not included
  • URL Routing is included

Now you can see why there’s been so much focus on Routing from the MVC team, as Routing is now part of the Framework and is not out-of-band. This meant that we had to put a lot more effort into Routing to make sure it was production ready.

ASP.NET MVC continues to be an out-of-band release. With the Routing code now effectively complete, you should hopefully start to see a lot more progress in MVC as our development team can focus almost exclusively on MVC.

MVC Preview 2 Apps Are Affected By SP1

Another important thing to note is that installing SP1 Beta installs the System.Web.Routing and System.Web.Abstractions assemblies into the GAC (Global Assembly Cache). These assemblies have the same exact assembly version as the ones we released as part of Preview 2.

What this means is that even though you might have a direct reference to the Preview 2 assemblies, when your app runs, it will still load those assemblies from the GAC.

We’ve posted the workaround for Preview 2 applications at the bottom of the page here in the section entitled Changes for ASP.NET MVC Preview 2.

April CodePlex Apps

If you’re running the April CodePlex app, you should be okay using the version from SP1 Beta. There might be minor behavioral differences in edge cases.

Preview 3

MVC Preview 3 will not be affected by having SP1 installed. Preview 3 will include newer privately versioned bin deployable builds of the Routing and Abstractions DLLs. That way these assemblies will not be affected by the versions in the GAC installed by SP1, because they will have different version numbers.

They don’t call it “Bleeding Edge” for nothing when playing with these previews, but we are sorry for the inconvenience and Preview 3 should make it better.

Technorati Tags: aspnetmvc,aspnet,net35sp1, mvc, code comments suggest edit

In my last post, I walked through a simple example of an ActionResult that you can use to transmit a file to the user’s browser along with a download prompt.

The MVC framework will include several useful action results for common tasks. However, we might not cover all results you might want to return. In this post, I walk through a simple result that will cover all remaining cases. With the DelegatingResult, you simply pass it a delegate. This provides ultimate control. Let’s see it in action.

public ActionResult Hello() {
  return new DelegatingResult(context => {
    context.HttpContext.Response.AddHeader("something", "something");
    context.HttpContext.Response.Write("Hello World!");

Notice that we pass in a lambda to the constructor of the action result. This lambda is a delegate of type Action<ControllerContext>. By doing this, the lines of code within that block (Response.AddHeader and Response.Write) are deferred till later.

Here’s the code for this action result.

public class DelegatingResult : ActionResult {
  public Action<ControllerContext> Command {
    private set;
  public DelegatingResult(Action<ControllerContext> command) {
    this.Command = command;

  public override void ExecuteResult(ControllerContext context) {
    if (context == null) {
      throw new ArgumentNullException("context");

I updated the sample I wrote in my last post to include this demo. Download the source.

Technorati Tags: aspnetmvc,actionresult,lambda, mvc comments suggest edit

NEW UPDATE: There is no longer need for this custom ActionResult because ASP.NET MVC now includes one in the box.

UPDATE: I’ve updated the sample to include a new lambda based action result. This also fixes an issue with the original download in which I included the wrong assembly.

The April CodePlex source drop of ASP.NET MVC introduces the concept of returning an ActionResult instance from action methods. ScottGu wrote about this change on his blog.

In this post, I’ll walk through building a custom action result for downloading files. As you’ll see, they are extremely easy to build. Let’s start at the end and see what the end-user behavior of this new result will be.

Here’s a page that contains a link to an action method named Download.This action method returns this new DownloadResult action result.

File Download

Clicking on the link then pops up this dialog, prompting you to download and save the file.


The code for this action is pretty simple.

public ActionResult Download() 
  return new DownloadResult 
    { VirtualPath="~/content/site.css", FileDownloadName = "TheSiteCss.css" };

Notice that you just need to give the result two pieces of information, the virtual path to the file to send to the browser and the default filename to save the file as on the browser.

The virtual path is set via VirtualPath property (surprise surprise!). Note that I could have chosen to make this parameter accept the full file path instead of a virtual path, but I didn’t want to force users of this class to fake out a Server.MapPath call in a unit test. In any case, the change is trivial for those who prefer that approach. I might add overloads that accept a Stream, etc…

The file download name is set via the FileDownloadName property. Notice that this is the filename that the user is prompted with.

If the FileDownloadName property is set, the ExecuteResult method makes sure to add the correct content-disposition header which causes the browser to prompt the user to save the file.

For those familiar with Design Patterns, action results follow the pattern commonly known as the Command Pattern. An action method returns an instance that embodies an command that the framework needs to perform next. This provides a means for delaying the execution of framework/pipeline code until after your action method is complete, rather than from within your action method, which makes unit testing much nicer.

Speaking of unit tests, here’s the unit test for that download action method I wrote. As you can see, it is quite simple.

public void DownloadActionSendsCorrectFile() {
  var controller = new HomeController();

  var result = controller.Download() as DownloadResult;

  Assert.AreEqual("TheSiteCss.css", result.FileDownloadName);
  Assert.AreEqual("~/content/site.css", result.VirtualPath);

Here’s the code for the DownloadResult class. This is the class that does all the work (not that there is much work to do). I do have unit tests of this class in the included source code which demonstrate how to unit test a custom action result.

public class DownloadResult : ActionResult {

  public DownloadResult() {

  public DownloadResult(string virtualPath) {
    this.VirtualPath = virtualPath;

  public string VirtualPath {

  public string FileDownloadName {

  public override void ExecuteResult(ControllerContext context) {
    if (!String.IsNullOrEmpty(FileDownloadName)) {
        "attachment; filename=" + this.FileDownloadName)

    string filePath = context.HttpContext.Server.MapPath(this.VirtualPath);

I removed the download since this code is no longer needed nor relevant.

Technorati Tags: aspnetmvc,actionresult, mvc comments suggest edit

A while back I wrote a routing debugger which is useful for testing your routes and seeing which routes would match a given URL. Rob suggested we have something like this for unit tests, so I whipped something simple up.

This is a class that allows you to test multiple different URLs quickly. You simply create the RouteEvaluator giving it a collection of routes and then GetMatches which returns a List<RouteData> containing a RouteData instance for every route that matches, not just the first one.

Here’s a sample of usage.

public void CanMatchUsingRouteEvaluator()
  var routes = new RouteCollection();

  var evaluator = new RouteEvaluator(routes);
  var matchingRouteData = evaluator.GetMatches("~/foo/bar");
  Assert.IsTrue(matchingRouteData.Count > 0);
  matchingRouteData = evaluator.GetMatches("~/foo/bar/baz/billy");
  Assert.AreEqual(0, matchingRouteData.Count);

And here’s the code. Note that my implementation relies on Moq, but you could easily implement it without using Moq if you wanted to.

public class RouteEvaluator
  RouteCollection routes;
  public RouteEvaluator(RouteCollection routes)
    this.routes = routes;

  public IList<RouteData> GetMatches(string virtualPath)
    return GetMatches(virtualPath, "GET");

  public IList<RouteData> GetMatches(string virtualPath, string httpMethod)
    List<RouteData> matchingRouteData = new List<RouteData>();

    foreach (var route in this.routes)
      var context = new Mock<HttpContextBase>();
      var request = new Mock<HttpRequestBase>();

      context.Expect(ctx => ctx.Request).Returns(request.Object);
      request.Expect(req => req.PathInfo).Returns(string.Empty);
      request.Expect(req => 
      if (!string.IsNullOrEmpty(httpMethod))
        request.Expect(req => req.HttpMethod).Returns(httpMethod);

      RouteData routeData = this.routes.GetRouteData(context.Object);
      if (routeData != null) {
    return matchingRouteData;

Let me know if this ends up being useful to you.

Technorati Tags: aspnetmvc,ASP.NET,routing, mvc, personal comments suggest edit

I did another interview with those wild and crazy guys, Carl and Richard. My first time (show 261) being on .NET Rocks was back in August of 2007 when I talked about Subtext, Open Source, and my blog.

This time (show 339), the interview focused on my experiences with working at Microsoft and the work I do on the ASP.NET MVC project. Notice that my profile pic hasn’t changed at all. I should do something about that.

I haven’t listened to it yet as I hate hearing myself talk. Even worse is seeing myself on video.

In any case, if you are interested, take a listen to the latest .NET Rocks show.

Oh, and I was also a guest on Hanselminutes recently. That talk was recorded at ALT.NET Open Spaces in Seattle. It’s only a coincidence that these two interviews came out a week apart. They were recorded more than a week apart. Honestly, I’m not a microphone whore. I’m more of a camera whore. ;)

Technorati Tags: dotnetrocks, mvc, code comments suggest edit

Not long ago, my compadre Scott Hanselman related the following story

In a recent MVC design meeting someone said something like “we’ll need a Repeater control” and a powerful and very technical boss-type said:

“We’ve got a repeater control, it’s called a foreach loop.”

I beg to differ. I think we can do better than a foreach loop. A foreach loop doesn’t help you handle alternating items, for example. My response to this story is, “The foreach loop is not our repeater control. Our repeater control is an iterating extension method with lambdas!”. Because who doesn’t love lambdas?

Not many people realize that within an ASPX template, it’s possible to pass sections of the template into a lambda. Here, let me show you the end result of using my Repeater<T> helper method. It’s an extension method of the HtmlHelper class in ASP.NET MVC.

  <% Html.Repeater<Hobby>("Hobbies", hobby => { %>
  <tr class="row">
    <td><%= hobby.Title %></td>
  <% }, hobbyAlt => { %>
  <tr class="alt-row">
    <td><%= hobbyAlt.Title %></td>
  <% }); %>

This renders a table with alternating rows. The Repeater method takes in two lambdas, one which represents the item template, and another that represents the alternating item template.

This particular overload of the Repeater method takes in a key to the ViewData dictionary and casts that to an IEnumerable<T>. In this case, it tries to cast ViewData["Hobbies"] to IEnumerable<Hobby>. I’ve included overloads that allow you to explicitly specify the items to repeat over.

This isn’t very remarkable when you think a bout it. What the above template code translates to is the following (roughly speaking)…


Html.Repeater<Hobby>("Hobbies", hobby => {
    Response.Write("  <tr class=\"row\">");
    Response.Write("    <td>");
    Response.Write("    </td>");
    Response.Write("  </tr>");
  }, hobbyAlt => { 
    Response.Write("  <tr class=\"alt-row\">");
    Response.Write("    <td>");
    Response.Write("    </td>");
    Response.Write("  </tr>");


The code for the Repeater method is simple, short, and sweet.

public static void Repeater<T>(this HtmlHelper html
  , IEnumerable<T> items
  , Action<T> render
  , Action<T> renderAlt)
  if (items == null)

  int i = 0;
  items.ForEach(item => {
    if(i++ % 2 == 0 ) 

public static void Repeater<T>(this HtmlHelper html
  , Action<T> render
  , Action<T> renderAlt)
  var items = html.ViewContext.ViewData as IEnumerable<T>;
  html.Repeater(items, render, renderAlt);

public static void Repeater<T>(this HtmlHelper html
  , string viewDataKey
  , Action<T> render
  , Action<T> renderAlt)
  var items = html.ViewContext.ViewData as IEnumerable<T>;
  var viewData = html.ViewContext.ViewData as IDictionary<string,object>;
  if (viewData != null)
    items = viewData[viewDataKey] as IEnumerable<T>;
    items = new ViewData(viewData)[viewDataKey] as IEnumerable<T>;
  html.Repeater(items, render, renderAlt);

Some of the ViewData machinations you see here is due to the fact that ViewData might be a dictionary, or it might be an unknown type, in which case we perform the equivalent of a DataBinder.Eval call on it using the supplied view data key.

It turns out that the regular <asp:Repeater /> control works just fine with ASP.NET MVC, so there’s no need for such an ugly method call. I just thought it was fun to try out and provides an alternative approach that doesn’t require databinding.

UPDATE: I wanted to end this post here, but my compadre and others took exception to my implementation. Read on to see my improvement…

As astute readers of my blog noted, the example I used forces me to repeat a lot of template code in the alternative item case. The point of this post was on how to mimic the repeater, not in building a better one. Maybe you want to have a completely different layout in the alternate item case. I was going to build a another one that relied only on one template, but I figured I would leave that to the reader. But noooo, you had to complain. ;)

So the following is an example of a repeater method that follows the most common pattern in an alternating repeater. In this common case, you generally want to simply change the CSS class and nothing else. So with these overloads, you specify two CSS classes - one for items and one for alternating items. Here’s an example of usage.

  <% Html.Repeater<Hobby>("Hobbies", "row", "row-alt", (hobby, css) => { %>
  <tr class="<%= css %>">
    <td><%= hobby.Title%></td>
  <% }); %>

And here’s the source for the extra overloads. Note that I refactored the code for getting the enumerable from the ViewData into its own method.

public static void Repeater<T>(this HtmlHelper html
  , IEnumerable<T> items
  , string className
  , string classNameAlt
  , Action<T, string> render)
  if (items == null)

  int i = 0;
  items.ForEach(item =>
    render(item, (i++ % 2 == 0) ? className: classNameAlt

public static void Repeater<T>(this HtmlHelper html
  , string viewDataKey
  , string cssClass
  , string altCssClass
  , Action<T, string> render)
  var items = GetViewDataAsEnumerable<T>(html, viewDataKey);

  int i = 0;
  items.ForEach(item =>
    render(item, (i++ % 2 == 0) ? cssClass : altCssClass);

static IEnumerable<T> GetViewDataAsEnumerable<T>(HtmlHelper html, string viewDataKey)
  var items = html.ViewContext.ViewData as IEnumerable<T>;
  var viewData = html.ViewContext.ViewData as IDictionary<string, object>;
  if (viewData != null)
    items = viewData[viewDataKey] as IEnumerable<T>;
    items = new ViewData(viewData)[viewDataKey] 
      as IEnumerable<T>;
  return items;

Hopefully that gets some people off my back now. ;)

Technorati Tags: aspnetmvc, mvc, code comments suggest edit

File this one away for the next time your boss comes in and asks,lumberg[1]

Yeaaah, I’m going to need you to make that little change to the code. It’ll only take you a couple hours, right?

Software has this deceptive property in which some changes that seem quite big and challenging to the layman end up being quite trivial, while other changes that seem quite trivial, end up requiring a lot of thought, care, and work.

Often, little changes add up to a lot.

I’m going to walk through a change we made that seemed like a no-brainer but ended up having a lot of interesting consequences that were invisible to most onlookers.

The Setup

I’ll provide just enough context to understand the change. The project I work on, ASP.NET MVC allows you to call methods on a class via the URL.

For example, a request for /product/list might call a method on a class named ProductController with a method named List. Likewise a request for /product/index would call the method named Index. We call these “web callable” methods, Actions. Nothing new here.

There were a couple rules in place for this to happen:

  • The controller class must inherit from the Controller class.
  • The action method must be annotated with the [ControllerAction] attribute applied to it.

We received a lot of feedback on the requirement for having that attribute. There were a lot of good reasons to have it there, but there were also a lot of good reasons to remove it.

Removing that requirement should be pretty simple, right? Just find the line of code that checks for the existence of the attribute and change it to not check at all.

The Consequences

Ahhh, if only it were that easy my friend. There were many consequences to that change. The solutions to these consequences were mostly easy. The hard part was making sure we caught all of them. After all, you don’t know what you don’t know.

Base Classes

So we removed the check for the attribute and the first thing we noticed is “Hey! Now I can make a request for /product/gethashcode, Cool!

Not so cool. Since every object ultimately inherits from System.Object, every object has several public methods: ToString(), GetHashCode(), GetType(), and Equals(), and so on… In fact, our Controller class itself has a few public methods.

The solution here is conceptually easy, we only look at public methods on classes that derive from our Controller class. In other words, we ignore methods on Controller and on Object.

Controller Inheritance

One of the rationales for removing the attribute is that in general, there isn’t much of a reason to have a public method on a controller class that isn’t available from the web. But that isn’t always true. Let’s look at one situation. Suppose you have the following abstract base controller.

public abstract class CoolController : Controller
  public virtual void Smokes() {...}

  public virtual void Gambles() {...}

  public virtual void Drinks() {...}

It is soooo cool!

You might want to write a controller that uses the CoolController as its base class rather than Controller because CoolController does some cool stuff.

However, you don’t think smoking is cool at all. Too bad, Smokes() is a public method and thus an action, so it is callable. At this point, we realized we need a [NonAction] attribute we can apply to an action to say that even though it is public, it is not an action.

With this attribute, I can do this:

public class MyReallyCoolController : CoolController
  public override void Smokes()
    throws new NotImplementedException();

Now MyReallyCoolController doesn’t smoke, which is really cool.


Another issue that came up is interfaces. Suppose I implement an interface with public methods.  Should those methods by default be callable? A good example is IDisposable. If I implement that interface, suddenly I can call Dispose() via a request for /product/dispose.

Since we already implemented the [NonAction] attribute, we decided that yes, they are callable if you implicitly implement them because they are public methods on your class and you have a means to make them not callable.

We also decided that if you explicitly implement an interface, those methods would not be callable. That would be one way to implement an interface without making every method an action and would not require you to annotate every interface method.

Special Methods

Keep in mind that in C# and VB.NET, property setters and getters are nothing more than syntactic sugar. When compiled to IL, they end up being methods named get_PropertyName() and set_PropertyName(). The constructor is implemented as a method named .ctor(). When you have an indexer on a class, that gets compiled to get_Item().

I’m not saying it was hard to deal with this, but we did have to remember to consider this. We needed to get a list of methods on the controller that are methods in the “typical” sense and not in some funky compiler-generated or specially named sense.

Edge Cases

Now we started to get into various edge cases. For example, what if you inherit a base controller class, but use the new keyword on your action of the same name as an action on the base class? What if you have multiple overloads of the same method? And so on. I won’t bore you with all the details. The point is, it was interesting to see all these consequences bubble up for such a simple change.

Is This Really Going To Help You With Your Boss?

Who am I kidding here? Of course not. :) Well…, maybe.

If your boss is technical, it may be a nice reminder that software is often like an iceberg. It is easy to see the 10% of work necessary, but the other 90% of work doesn’t become apparent till you dig deeper.

If your boss is not technical, we may well be speaking a different language here. I need to find an analogy that a business manager would understand. A situation in their world in which something that seems simple on the surface ends up being a lot of work in actuality. If you have such examples, be a pal and post them in the comments. The goal here is to find common ground and a shared language for describing the realities of software to non-software developers.

Technorati Tags: Software,Software Design,ASP.NET MVC