IHttpModule not running after conversion to IIS 7 and .NET 3.5

I recently ran into this problem with one of our clients. It’s the sort of thing that I take ages to track down a solution to, and then once I have solved it, I immediately forget what the solution is. So I’m putting it here as an aid memoire.

The client had a module that they were using to create a custom Principal object derived from a FormsPrincipal. I found that after I had converted the project to work with VS.NET 2008 beta 2, it stopped working, giving me a GenericPrincipal instead. I had converted the client’s project to .NET 3.5 from .NET 2.0 and I was also using IIS 7 where they were using IIS 6 in production and IIS 5 for dev. There were a few variables that made it not very straightforward to solve, not least of which is that nothing is easy to find in IIS 7 (when you’re so used to IIS 6).


First step: find the blasted thing that shows you what managed modules you’ve got.



Double click on it, and you will be shown a list of what modules apply for the application you’re working with.

Sort the modules by type.


What I found was that my web.config file had entries for two modules:


But IIS 7 claimed I had only one.


I tried a load of different things, like rearranging the order of the modules, putting tracing on the lifecycle events of the module, and adding more detailed version info on the fully qualified type name of the module. All to no avail. Then I noticed that IIS offered the ability to add you own modules.


So I clicked on the “Add Managed Module…” link, and entered the details that were already in the web.config file, and hey presto! It replaced the contents of the modules section in the web.config with exactly the same data. But this time it was also reflected in the modules area of IIS 7.


Don’t ask me why – it’s probably something to do with the IIS 7 metabase, but I don’t know. Certainly, it wasn’t anything wrong with the config file.


4 thoughts on “IHttpModule not running after conversion to IIS 7 and .NET 3.5

  1. Andrew,

    This is an effect of the managed pipeline in IIS7.

    If you are running under the integrated (managed) pipline, then module and handler configuration is read from (note the addition of “Server”).

    If you revert to the classic pipeline it will read your config like it used to.

    Normally, when you load a classic app that defines modules and handlers it gives you a 500 error and forces you to upgrade or switch the pipeline mode. The error page gives clear instructions on how to do this.

    If you have a look at your web.config now tahat you added the module in the GUI, you will notice it has added the configuration for you there. The GUI wasn’t actually editing the metabase.

    Take a look at:



  2. Thanks for your note.
    But if user don’t have access to the IIS, then is there any other way to do the same?


Comments are closed.

Create a website or blog at WordPress.com

Up ↑

%d bloggers like this: