Getting started with IIS is trick

January 16th, 2008

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 ;-)

Categories: General | Top Of Page | 5 Comments » |

5 Responses to “Getting started with IIS is trick”

MIke Says:

Is the NullRef exception you were getting the same as the one here:

I got that when I moved my monorail app to IIS7 before I put in the new system.webServer config elements.

I compiled my experiences here…

Not sure if that helps…

hammett Says:

Nope, it’s on System.Web.SomethingContainer… I’ve tried the migrate config when I was into the integrated mode. I’ve asked the provider to upgrade to RC1 and see how it goes…

vedic Says:

now that almost all castle sites seem to be down…
… I believe you! ;)

Adam Tybor Says:

I wasn’t able to get it to work either. I resorted to the old dual application trick. I have my mr app and a /assets application underneath. I cleared every handler from the /assets application except the static handler. Probably didn’t need to do that but why not, its only serving static files.

Bryan Says:

One trick is to change the static file matching to *.*.

Follow this:

Leave a Reply