Zen and the art of Castle maintenance

Moving my web apps to a new dedicated server with Windows Server 2008 (b6001) has not been a pleasant experience so far. After reading and digesting the differences between Class and Integrated mode, I’ve obviously gone for the integrated path. After setting up the app I got a NullReferenceException. Nope, not on MonoRail, not on my code whatsoever. On System.Web code. .Net 2. Something related to GetEventCount. Now, even if I fire up Reflector and digged, would I be able to fix it or work around it? I don’t think so.

So falling back to Classic. This one works fine except for one thing. In my web site I have used MR old fashion Routing based on IIS wildcard mappings. Works like this:

You request /home/index

IIS dispatches this to your configured wildcard handler (which happens to be the ASP.Net Isapi extension). This gets dispatches to a module, that matches or not the url and rewrites it. Cool. Works fine on IIS 5 and 6.

Now, on IIS 7 there has been some changes. Cool changes, but that breaks my legs nevertheless – am I the only one?. Here’s the deal:

They now have a handler for static files, which happens to be a wildcard mapping (*).
The old fashion rewriting routing works with a wildcard mapping (*).

What you have? A conflict.

  Step 1: Disabling one and enabling other to make sure both works

Yep, the routing works fine. The static works fine. Fantastic

  Step 2: Disambiguating them

So my idea was: if I can rely on their restrictions, I can get one running and then the other. For instance, the static handler will (or should) only run for a file that is physically present on the file system. IIS 6 had something like “Check that the file exists”. On IIS 7 there’s something that I think is similar, might not be: Invoke handler only if request is mapped to: File | Folder | File or Folder.

So the disambiguation is simple: the routing runs for things that does not exists physically. The static handler runs for existing one.

Configured both and got:

/content/css/mycss.css -> Failed to Execute URL

Ok, so something still wrong.

  Step 3: Ordering them

So if I get the static handler running (or being considered as an optimal handler) before the routing one, things shall work.

Click on “View Ordered List”. Move up, move down.

Time to test!

/content/css/mycss.css -> Failed to Execute URL

Ok, so looks like ordering doesn’t matter or the restrictions aren’t exactly what I think.

  Step 4: Crying for help

I’m sure someone will comment with “just click this and that and you’re done” making me look stupid and totally inexperienced. I give you that, I’m stupid and inexperienced, so now it’s your turn: show me the light ;-)