IIS 7 introduces two operating modes
- New Integrated mode, when all served requests are processed by ASP.NET pipeline
- Classic mode is legacy mode used for backward compatibility. All requests are served by IIS based on its extension handlers configuration. This is how IIS worked before IIS 7. This could make some problems running HttpModules that works correctly with Integrated mode
There is a difference in configuring HttpModule in web.config for Integrated and Classic Mode
When you see Http Error 500, its probably misconfigured web.config. There are two ways how to do this
Migrating web.config automatically
You can migrate web.config automatically with appcmd (IIS command) typing:
|%windir%\system32\inetsrv\Appcmd migrate config “<ApplicationPath>”|
or, what I prefer more is to move manually.
Migrating web.config manually
You need to move following HttpHandlers entries:
into new IIS 7 sections (sytem.webServer)
and then either remove old sections <httpHandlers> and <httpModules> or add an element into <system.webserver>:
<validation validateIntegratedModeConfiguration=”false” />
Disabling Integrated Mode Configuration validation is better when you need your application working in Classic and Integrated mode, because you then need to have both sections in the web.config.
Classic mode is some kind of backward compatibility mode in IIS. Until IIS 7, ASP.NET was hosted inside IIS as so called ISAPI module. IIS process was unmanaged application (did not need .Net Framework) and ASP.NET application was hosted in managed environment as a plugin. That means, that all requests started processing by IIS process itself and based on some configured rules, processing could be passed to ASP.NET runtime.
Problems with HttpModules in Classic mode
When IIS 7 processes requests in Classic mode, IIS operates the same way and it does in IIS 6. For each request, IIS decides what handler to use, based in handlers configuration for a site. This decision is made based on extension of requested file. When we want to write some redirect plugin, your application will usually redirect from some non-existing content, or at last from some content without specified extension.
What this mean is when you look at the Handler Mapping configuration table in IIS.
This mapping will process all requests with .aspx extension with isapi module. Which one is that can be found by double click to see configuration details on that selected handler mapping.
And we can see, that .aspx pages are processed in a ISAPI module called aspnet_isapi.dll. This is basically unmanaged dll that creates managed environment to run ASP.NET content.
Our URI request is not processed by ASP.NET without .aspx extension
As you probably realized, when your request looks like:
Where is no extension, it does not reach ASP.NET ISAPI module in classic mode processing and the request will finish with HTTP Error 404 – Not Found.
To get over that problem, we need to configure wildcard (*) or any extension to be processed by ASP.NET ISAPI handler.
We need to go to handler mappings again, click to Add Wildcard Script map and configure it to process with aspnet_isapi.dll. Whole path to that dll can be copied from .aspx handler mapping. In the end the dialog should look like:
Where the Name of Handler mapping could be anything meaningful.
On the dialog asking to to allow this extension, you should choose Yes.
Next step is to switch Handler Mappings to Ordered view (to see in what order of processing goes our handler) by clicking to View Ordered List.
In Ordered view, you need to move the new mapping almost at the bottom, right above Static File mapping.
Before we finish, you need to find out, whether your computer runs 64bit Windows. When yes, you probably have .NET also in 64 bit variant. For the case, you have your code compiled for x64bit platform and IIS will process it using .NET 64 (by default if not specified), you also need to specify Wildcard handler mapping for aspnet_isapi.dll. You should proceed the same steps as above except the path will point to 64bit aspnet_isapi.dll.
For finding the path of aspnet_isapi.dll, you can look into configuration of “PageHandlerFactory-ISAPI-2.0-64”, but in most cases it is in “%windir%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll”
Again, you need to enter some meaningful name like “ASP.NET-ISAPI-2.0-64-Wildcard” and switch to ordered view and move new Handler Mapping right above Static File.
When finished, you should have no problem running HttpHandler in classic mode.