So I’m a n00b in some areas and it is painful finding this out sometimes. I spent most of the morning trying to figure out why my ASP.Net Web Site application wasn’t routing to my MVC controller that is inside of my ASP.Net MVC Area.

Granted, that is a weird setup so there are a lot of things I thought could possibly go wrong. The real reason was embarrassingly obvious, but not embarrassing enough that I wouldn’t post it for the world to see.

What do you see wrong with this route:

context.MapRoute(
    "Default Route",
    "ServerManagement/{controller}/{action}/{id}",
    new {   controller = "farms",
            action = "index"
        });

Give up? You have to give a default value if you have a placeholder in the route. In this case we have “/{id}” in the route, but we never a default value for the id. The following route worked fine.

context.MapRoute(
    "Default Route",
    "ServerManagement/{controller}/{action}/{id}",
     new {   controller = "Farms",
             action = "index",
             id=""
         });

Lesson learned!

It’s nice when fixing a problem is easy.  It’s nice when you scratch your head for a bit and then smack your forehead because someone in front of you laid out exactly what to do, and exactly what needs to be done.  I just had such a moment.

While working MVC into out existing ASP.Net Web Site project we hit, what we thought was a brick wall.

HTTP Error 500.22 - Internal Server Error
An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.

Well the Visual Studio engineers deserve a hand for helping me get this going.  After spending a minute looking into the web.config to find out what was wrong, I ran into this little bit of commented out configuration.

<!--
        The system.webServer section is required for running ASP.NET AJAX under Internet
        Information Services 7.0.  It is not necessary for previous version of IIS.

	<system.webServer>

        ...then some more config

That is exactly what was needed to take us into integrated mode in IIS, which is needed for MVC.

Let’s face it. Everyone loves MVC. At least all the web purists love it. It’s clean, straight forward, and very testable. But let’s also face it. We have a huge investment in WebForms. I mean up until now, 100% of the stuff we built was WebForms, include 100% of the master pages.

These pages govern how  the entire site looks and a wee bit of its functionality.

It would be a real shame if we had to start being less DRY and copy all that markup, in potentially many files, to new, MVC master pages. Luckily, you don’t.

Let me stop right there. Technically, no, you don’t. Mvc’s ViewMasterPage (VMP) inherits from MasterPage (MP), so you can just tell your VMP to use the MP you want and it will work, unless you have the single line I hate more than any other lines in your MP.

<form id=”Form1” runat=”server”>

So this single line blows the possibility of using the master page as a VMP out of the water. No problem right, include that in a nested MP and put that runat=”server” around the content place holder, right?

That’s nice and all, but all those other bit out side of the WebForms specific master page needs to be inside that stupid form.

Uh oh! No way around that one! Either move the run at server form outside or convert those controls. I’d vote for convert the controls.

OK, so how about just use partial views and HtmlHelpers. That sounds like a good idea. Here’s another problem.

<%= Html.MyMenu() %>

System.Web.UI.MasterPage does not have a HtmlHelper attribute where we get all those nice HtmlHelper Extensions. What about just creating one and using it?

<%= new HtmlHelper(null,null).MyMenu() %>

Great! That compiles, but don’t get too excited. It doesn’t run. We can’t just pass null into HtmlHelper. We can new up the first parameter and create our own custom implementation of the second and it does work.

<%= new HtmlHelper(new ViewContext(), new FakeViewDataContainer).MyMenu() %>

That looks nasty too, but since that is my own customer helper extension, when not just call into that directly.

<%= MyMenuHelper.MyMenu(null) %>

That’s better, and since we aren’t using the HtmlHelper at all, we can clean up the syntax just a bit.

<%= MyMenuHelper.CreateMenu() %>

I can live with that, but if we ever need to do anything complicated that requires view data or other information to be passed along, we’re in a nasty situation. This works for us for now, so we’re going to ride this idea for a little longer and see how it goes.

Eventually all those WebForms pages will be moved over to MVC and this won’t be an issue. We’ll have only the MVC master page and everything will be simple.

I’m adding custom validation messages to all my data annotation validation attributes. Simple stuff right. I started off with this.

Then added a customer message.

Then moved that message to a resource file

The problem is the resource file says something like “Less than 50”. If I change that 50 on the attribute, someone has to remember to go to the resource file and change it there too. Not very DRY.

Luckily the default message formatting will allow us to embed some tokens in the error message.  All we need to do is change our message to “Less than {1}” and the message is formatted to “Less than 50”….or whatever the argument value might be.

I haven’t found a good list of the parameters you pass, but {0} is the property name, and then I assume 1, 2, 3, etc are the parameters of the constructor in order.

As I’ve mentioned we have a series of Extension methods that help with some trivial, but isolated tasks. Here is an example.

public static IEnumerable<SelectListItem> CreatePaymentTypeDropDownListItems(
                                          this IQueryable<PaymentType> @this)
{
    return  @this
            .OrderBy(x => x.Description)
            .Select(x => new SelectListItem
                             {
                                 Value = x.Code,
                                 Text = x.Description,
                             })
            .MarkAsSelected(x=>x.Text == CreditCard);
}

Simple enough right? The MarkAsSelected is another extension method we have to help out. It’s not all that exciting, but here it is.

public static IEnumerable
 MarkAsSelected(this IEnumerable
 @this, Func
 where)
{
    var items = @this.Where(where);
    foreach (var item in items)
    {
        item.Selected = true;
    }
    return @this;

}

Simple enough right? But the credit card payment type was never getting defaulted with the select value. We have unit tests around MarkAsSelected and it works! What’s the problem? Let’s try something really quick.

public static IEnumerable<SelectListItem> CreatePaymentTypeDropDownListItems(
                                          this IQueryable<PaymentType> @this)
{
    return  @this
            .OrderBy(x => x.Description)
            .Select(x => new SelectListItem
                             {
                                 Value = x.Code,
                                 Text = x.Description,
                             })
            .ToArray()
            .MarkAsSelected(x=>x.Text == CreditCard);
}

That works! What’s up? Oh you sneaky deferred execution. I bet it’s you! I’m not an expert, but here is my best guess. When the MarkAsSelected does its foreach, it asks the @this to create an enumerator. It does, but since it is from an IQueryable<T>, it now executes all that deferred execution in the Select and OrderBy. Fair enough. The enumerator spits out all the SelectListItems we want/need.

We pass on the enumerable incase we want to do something after it, and actually we do. Down the road we want to enumerate again. The Select and OrderBy kick in again and we get all brand new SelectListItems.

Throwing that ToArray in there gets us out of operating on the IQueryable<T>, does the Select and OrderBy and lets us operate on a straight list. Makes sense, but not obviously apparent…at least to me.

But you know what? After all that, I think I just prefer this.

public static IEnumerable<SelectListItem> CreatePaymentTypeDropDownListItems(
                                          this IQueryable<PaymentType> @this)
{
    return  @this
            .OrderBy(x => x.Description)
            .Select(x => new SelectListItem
                             {
                                 Value = x.Code,
                                 Text = x.Description,
                                 Selected = (x.Description == CreditCard)
                             });
}

No need to overcomplicate the problem right?

I was explaining my dilemma to a Java friend and the e-mail ended up being fairly interesting, so I thought I would share it.

I’m sure Java has extension methods, but I’ll give it a once over just in case.  You can extend existing classes without sub-classing by extension methods.

public static IEnumerable<SelectListItem>
                            AsSelectListItems( this IEnumerable<Person> listOfPeople){
   IList<SelectListItem> selectListItems = new List
();
   foreach(var person in listOfPeople){
      selecListItems.Add(new SelectListItem(person.ID,
					    string.Format("{0} {1} {2}",
                                                          person.First,
                                                          person.Middle,
                                                          person.Last));
   }
   return selectListItems;
}

Right. So the this operator tells the compiler to basically create this function:

public static IEnumerable<SelectListItem>
                           AsSelectListItems(IEnumerable<Person> listOfPeople);

And invoke it every time you see this:

IEnunerable<Person> p = myService.GetAllPeople();
IEnumerable<SelectListItem> s = p.AsSelectListItems();

You probably knew all this, but it explains how we are using them. We end up calling a lot of extension methods off other extension methods.

myViewData.PersonSelectListItems = myService.GetAllPeople()
                                                   .AsSelectListItems()
                                                   .OrderedByText()
                                                   .StartingWithAnEmptyItem();

In this example we have three extension method calls and I think it really makes the code much more readable, but it makes testing this code a little more difficult. Obviously, the myService is a mocked dependency which will return a fake list of people, but the other extension method calls cannot be mocked, and the scope of the test bleeds a bit.

I like the syntax it gives, but now I’m going to test potentially four classes when I should be testing only one.

This gets pretty pandemic in our code. Especially trying to make Selenium’s API and the assertion API of Nunit and xUnit more fluent.

We’re using the Data Annotations Validators in ASP.Net MVC 2.0, but there wasn’t a really great way to unit test them. I’ve read Brad Wilson’s blog post about how to set them up and unit test them, but I didn’t like how you relied on the name of the property as a string.

// Arrange
var propertyInfo = typeof(Contact).GetProperty("FirstName");

It would be nicer if that used lambda expressions to get the name of the property, so I set out to do just that. Before we begin, I need to remind you, as always, I don’t know what I’m doing. This is my first tiny venture into expression trees so it is possible isn’t the best way to do things, but so far, it’s working for me.

I created a base Specification to wrap up a lot of the messy bits of getting property names by lambdas. I took a look at how the ASP.Net MVC helpers did it and roughly followed their pattern.

public class DataAnnotationSpecification<T> : Specification
{

    public PropertyInfo Property(Expression<Func<T,object>> op)
    {
        return Property(GetInputName(op));
    }

    public PropertyInfo Property(string propertyName)
    {
        return typeof (T).GetProperty(propertyName);
    }

    public static string GetInputName<TProperty>(Expression<Func<T, TProperty>> expression)
    {
        // not sure I totally understand this
        if (expression.Body.NodeType == ExpressionType.Convert)
        {
            var ue = (UnaryExpression)expression.Body;
            return GetInputName((MemberExpression) ue.Operand );
        }

        if (expression.Body.NodeType == ExpressionType.MemberAccess)
        {
            return GetInputName((MemberExpression)expression.Body);
        }
        throw new NotImplementedException();
    }

    private static string GetInputName(MemberExpression memberExpression)
    {
        return memberExpression.Member.Name;
    }

}

I know this probably doesn’t cover an exhaustive list of expressions, but we’re only talking about Property access tests here so we’re probably in the clear.

To make things a bit nicer, I also created some extensions off PropertyInfo to help setup their assertions.

public static class AttributeAssertions
{

    public static void ShouldNotBeRequired(this PropertyInfo @this)
    {
        @this.ShouldNotHaveAttribute<RequiredAttribute>();
    }

    public static void ShouldBeRequired(this PropertyInfo @this)
    {
        @this.ShouldHaveAttribute<RequiredAttribute>();
    }

    private static T PropertyAttributeOn<T>(ICustomAttributeProvider propertyInfo)
    {
        return propertyInfo.GetCustomAttributes(typeof (T), false)
            .Cast<T>()
            .FirstOrDefault();
    }

    public static void ShouldHaveAttribute<T>(this PropertyInfo @this)
    {
        PropertyAttributeOn<T>(@this).ShouldNotBeNull();
    }
    public static void ShouldNotHaveAttribute<T>(this PropertyInfo @this)
    {
        PropertyAttributeOn<T>(@this).ShouldBeNull();
    }
}

We only have the ShouldBeRequired and ShouldNotBeRequired right now, but you could see it will be easy to extend upon them.  The finished spec looks something like this.

public class When_testing_the_state_of_the_CustomerViewData
    : DataAnnotationSpecification<CustomerViewData>
{
    [Then] public void the_customer_first_name_is_required()
    {
        Property(x => x.CustomerFirstName).ShouldBeRequired();
    }

    [Then] public void the_customer_middle_name_is_not_required()
    {
        Property(x => x.CustomerMiddleName).ShouldNotBeRequired();
    }

    [Then] public void the_customer_last_name_is_required()
    {
        Property(x=>x.CustomerLastName).ShouldBeRequired();
    }

    [Then] public void the_email_address_is_required()
    {
        Property(x=>x.CustomerEmailAddress).ShouldBeRequired();
    }

}

That’s not so bad, and it stands up to any refactoring we might do.

As a follow up to my previous post, testing when ModelState is relatively simple, but leaves me feelings a little uneasy about my tests.

Here is an example tests, stripped down to remove some of the unnecessary bits

public class When_submitting_lead_data_that_is_in_an_invalid_state : Specification
{
    // class fields...etc

    protected override void Given()
    {
        base.Given();
        _mockOrdersRepository = MockRepository.GenerateStub<IOrdersRepository>();
        _checkoutController = new CheckoutController(_mockOrdersRepository);

        _leadDataWithEmptyPlanName = new PreCheckoutViewData();

        // add an error to the model state
        _checkoutController.ModelState.AddModelError("", "");

        _exceptionWasThrown = false;
    }

    protected override void When()
    {
        base.When();
        try
        {
            _checkoutController.Checkout(_leadDataWithEmptyPlanName);
        } catch(ArgumentNullException)
        {
            _exceptionWasThrown = true;
        }
    }

    [Then] public void an_exception_is_thrown()
    {
        _exceptionWasThrown.ShouldBe(true);
    }
}

This feels pretty loose to me, but there can be another tests that tests which states the model will appear invalid.

We ran into a snag with using the new default Data Annotations Validation in ASP.Net MVC 2.0 Preview 2. Maybe it isn’t a snag, but it is not the behavior I would have expected.

Take the following model:

public class Person
{
  public string ID { get; set; }

  public string FirstName { get; set; }
  public string LastName { get; set; }

  [Required (ErrorMessage = "Required")]
  public string EmailAddress { get; set; }
}

Pretty straight forward, but if you post this form:

    <form action="/person/edit" method="post">
        <input type=hidden name="id" id="id" value="" />
        <input type="text" id="firstname" name="firstname" /> 
        <input type="text" id="lastname" name="lastname" /> 
        <input type="submit" />
    </form> 

To this controller action:

[HttpPost] public virtual ActionResult Edit(Person data)
{
   if (!ModelState.IsValid) throw new ItBrokeException();
   return View();
}

Personally, I would expect every post of that form to show up as invalid, but infact, it is always true. Add the following input to the form and it works.

   <input type="text" id="emailaddress" name="emailaddress" /> <br/>

After that, the ModelState.IsValid returns false, like it should.

After recently installing Visual Studio 2010 Beta 2 and creating a .Net 4.0 site, I tried to step out of Cassini and into IIS only to get “503 Service Unavailable” and a killed worker process. Checking the event viewer I found the following errors.

The worker process failed to initialize correctly and therefore could not be started.  The data is the error.

Followed by…

The worker process failed to pre-load .Net Runtime version v4.0.20506.

The Google was no help. It returned a handful of result that weren’t all that helpful, but one post was interesting. Someone had a similar problem with the  2.0 runtime when upgrading to the beta and found there were tiny bits of the other runtime sticking around.

I had .Net 4.0 Beta 1 installed before, so I did some digging and found I had the Beta framework:

C:\Windows\Microsoft.NET\Framework\v4.0.21006
C:\Windows\Microsoft.NET\Framework64\v4.0.21006

I also had folders from the Beta 1

C:\Windows\Microsoft.NET\Framework\v4.0.20506
C:\Windows\Microsoft.NET\Framework64\v4.0.20506

I deleted those folders, restarted the .Net 4.0 app pool’s and and hard restart just to be safe. Everything worked. Two hours on a Friday wasted, but we weekend free of worry.