Question

Web application initialization is as follows:

1. As we know when IIS receives the first request for a particular Asp.net application resource, IIS creates an instance of a HttpApplication (defined in global.asax codebehind).
2. When this new instance is created it’s initialization happens that also checks all configured HTTP modules.
3. All modules are then instantiated and put in the application’s Modules collection (of type HttpModuleCollection)
4. modules are looped through and their Init() method is called (when they register for request events)

As far as I understand it the above scenario happens when a web application is started/initialized (hence application start event).

What happens with modules?

Are they (re)instatiated on each request or reused from the Modules property on each consecutive request while the web application is alive? As I understand IIS and Asp.net they are reused through the whole life of a web application.

If they are reused, can we assume that their Init() method is actually a pseudo event handler for application start event? The thing is we can’t attach to application level events within http modules. But if they are being reused we could use Init() as application start event and do whatever we’d put in global.asax instead.

Question

Can we assume that module’s Init() method is called only on application start event? Could we use this assumption to i.e. register routes for applications whose global.asax codebehind we can’t change? web.config is usually accessible and we can change it the way we want.
Would this actually work?

Additional info

We can check HttpApplication code and check its InitModulesCommon() method. This one actually calls Init() of each registered HTTP module. What is more interesting is that this method is only used by InitIntegratedModules() and InitModules() methods. Which are both used only in HttpApplication.InitInternal() method. This is the basis of my assumptions, but I would like to know whether someone has abused IHttpModule.Init() for application start event.

Answer 1

Init() is called only once (per HttpApplication instance)

After I tested this the inner workings of IHttpModule initialization are as follows:

1. Every IHttpModule is initialized at web application start by instatiating and a call to Init() method
2. HttpApplication stores all module instances in its Modules property
3. Modules are then reused for the whole life of an HttpApplication and are not discarded/reinitialized as long as the application is alive

So the best outcome is

You can’t attach an IHttpModule to application level events, but you can use its Init() method as pseudo application start event delegate. Inside it you can execute any code that you’d usually put inside Application_Start delegate in your Global.asax.

You can also read detailed information about it in my blog post.

But be careful in real-life web server environment

But IIS uses something called application pools. And each pool can have an arbitrary number of HttpApplication instances. Yes multiple. Application starting creates all these instances. Every one of them initializes their own list of modules but only the first one executes the Application_OnStart event handler.

So whenever your module modifies some common shared resource, you should take extra measures to indicate that the first module has done that and others won’t do it again. Read an additional blog post about it that will show you how and when to use thread locking with your module to make it actually act as an Application_OnStart event handler. BTW: It’s also possible to handle Application_OnEnd event if you need to. 😉

Detailed blog post links

1. Writing a custom IHttpModule that handles Application_OnStart event
2. How to correctly use IHttpModule to handle Application_OnStart event