I recently upgraded to Vista on my developing machine, and it has worked like a charm. Although the other day I ran in to some problems with IIS7 , as I was going to do some work on a website that uses URL rewriting to make some nice search engine friendly URL's.

I published my project to localhost, and fired up a browser, and got the message: http-error 403.14 - forbidden as shown below (my Vista is in Danish, so these screenshots may by gibberish to you):

I had set my startpage as something like "frontpage" with no extension and on IIS6 i just set up a wildcard mapping to route any request through the aspnet_isapi.dll, and then handled the forwarding with internal logic.

Rather baffled i studied the message suspecting of course that it had something to do with wildcard mappings, so I opened the IIS Manager to take a look at the StaticFile handler that is mentioned in the error message.

In the IIS Manager choose Handler Mappings in the IIS section, and you will get the following screen, where we can see the StaticFile handler:

I noticed that it was set to match * and that got me thinking. What I need is really a wildcard match that passes all request to aspnet_isapi.dll, and as all the static files have extensions, I should set the StaticFile Handler to process *.*

So first I setup a new Script Map to map all requests to aspnet_isapi.dll - this is just like in IIS6.

Then push the "Request restrictions" button and you will get the screen below, where you unselect the Invoke handler checkbox.

When you press ok to the choices, you will be prompted to allow enabling of the ISAPI extension. Choose yes in the dialog.

Now we want to set the StaticFile Handler, that is currently reporting the error, to only handle files with an extension.

So now I think I'm good to go, and I try to launch my page again. But theres still seems to be a problem.

 As suggested in the message I consult the Event Log for an explanation, and i get this message:

A request mapped to aspnet_isapi.dll was made within an application pool running in Integrated .NET mode. Aspnet_isapi.dll can only be used when running in Classic .NET mode. Please either specify preCondition="ISAPImode" on the handler mapping to make it run only in application pools running in Classic .NET mode, or move the application to another application pool running in Classic .NET mode in order to use this handler mapping.

After some research I decide - that even though there may be better ways to create URL Rewriting with IIS7 - what I need is to get this application on the road in hurry, and therefore I go with the second option, and set the application to run in Classic .Net mode, which can be done by right-clicking the website in the IIS Manager and choosing Advanced options, and setting the App Pool to "Classic .Net AppPool" :

Again I'm optimistic and thinking that this should do the trick, and I refresh the page in the browser, but still there is something not quite right - no static files still? When I try to access an image file on the server I get the error: Failed to Execute URL.

At this point I am getting a little discouraged and I stare at the Handler Mapping Section for a while until i notice a little link in the menu in the upper right side that says: "View ordered list". Aha, I think, obviously the ordered list shows the order in which the handlers are being executed for a request.

The Wildcard script map we added earlier is at the top, and then the static files won't get processed by the StaticFile Handler. So what we need to do is, to move the Wildcard handler below the StaticFile Handler:

For some unexplainable reason I need to move the mapping twice in order for it to stay in the position. This happened again when I was going through the steps again while writing this walk-through. But second time you move it, it stays there. And voila, the page renders perfectly:

I would not recommend this approach unless you need a quick hack to simulate IIS6 setup, but as such it does the trick for me on my development station, where I do development that is deployed to non IIS7 servers. This solution is presented as is, and I give no warranty that it will solve your problem.