Contents tagged with Modules
Modules are a great extensibility mechanism because they allow us to glimpse into a request and to do something before the response is sent back.
Sometimes, you may want to change the page – add some contents, change the properties of controls, etc. – in a module, so that you can reproduce the behavior for all (or some) pages in an easily reusable way. For that, ASP.NET offers a great number of events, that compose the request lifecycle.
Say you want to inject custom content to the page; you might be surprised to find that if even if you choose what appears to be a right event, the injected content does not show up!
Next in the series is modules. So, what is a module, and what does it do?
A module is some class that implements IHttpModule. This is a very simple interface, which only defines two methods:
- Dispose: called when the application shuts down.
A module is typically statically registered on the Web.config file, although I have talked in the past on how to register modules dynamically. While a module usually does not actually do anything by itself, it is useful for registering event handlers for ASP.NET application lifetime events, such as Error, BeginRequest, EndRequest and their likes. Please note that there is no event for the Start occurrence (normally handled on the custom Global class on an Application_Start method), you can just use the Init method for that, since it is called upon application startup.
Out of the box ASP.NET includes a number of modules, which you can find on the global Web.config file, located in %WINDIR%\Microsoft.NET\Framework64\v4.0.30319\Config, some of which you are free to disable, that is, remove on you local Web.config file:
As you can see from the above snippet, one such module is PassportAuthentication, implemented by PassportAuthenticationModule, one that is marked as deprecated in current versions of .NET. Now, there are two sections where modules can be registered, one for IIS versions prior to 7, and the other for recent versions. Of course, if you only use one of them, do forget about the other section.
A simple module implementation would be:
This module registers an event handler for the EndRequest event, which, when called, outputs a string to the response. Nothing to be done on disposing, in this case, but a typical use case would be to release any sort of “heavy” module-held resources when the application shuts down. Please be careful to perform operations only when you can, for example, session is only available after the AcquireRequestState event is raised (and, of course, only for handlers implementing IRequiresSessionState), caller identity is only set after the AuthenticateRequest and authorization is only confirmed after AuthorizeRequest.
You should favor writing code that handles an event in a module as opposed to having a similar method on Global.asax.cs because a module is more portable – you can even reuse it between different assemblies.
Once you are finished, you need to register your module on Web.config, to have it being set up automatically. You have to give it a unique name and add an entry like the following:
Next, handlers and routes!
As you may already know, ASP.NET 4.0 brought along with it a new mechanism to execute methods before the application start event (the Application_Start method): the PreApplicationStartMethodAttribute. This attribute, when applied to an assembly, indicates a method which is to be run before the application starts. If your web application references any assembly which has this attribute, it will run the method it declares, throwing an exception it if is not found.