The case of global.asax not being executed in IIS7
Global.asax is used in both asp.net MVC and OpenRasta for implementing your configuration. In Rasta 1.x, the handling of request was done through a catchall http handler. This has a couple of adverse effects for the application: all requests went through rasta first, and got delegated to IIS when there was no match. This can cause a range of performance issues, from lack of caching to constant file access when the delegation ends up using DefaultHandler rather than StaticHandler, as in those instances the files will systematically be streamed from the disk.
Another struggle I had with this system was the various issues encountered when trying to host the system on IIS7, something I started doing a while ago. I remembered reading from a blog that asp.net MVC was using both a handler and an http module, and investigated using a similar configuration for OpenRasta. As I do not want to be influenced by other people’s coding abilities, I have stayed away from reading the asp.net MVC source-code and tried to come up with my own scheme.
One particular issue comes from the different framework versions supported by OpenRasta: I run on plain old asp.net 2, and this means that all the new APIs that let you change a handler on the fly during a request will not work, as they are added by .net 3.5 sp1. Instead I came up with a clever trick: Just before the handler is resolved, I rewrite the url to a fake url, properly called ignoreme.rastahook. The extension rastahook is always associated with a compatibility handler that then gets called by the asp.net infrastructure, at which point I rewrite the url to what it was before the change, and execute my own http handler from there. The solution is not entirely perfect yet, as there is no support for asynchronous handlers, but as with every other part of OpenRasta I’ll be able to change that without impacting any handler already in existence.
As soon as I implemented those changes, everything went much more smoothly on IIS6 and cassini (the visual studio web server), but broke completely on IIS7 integrated mode on my local box. After much debugging, I realized that my global.asax wasn’t being called. When I added back an http handler to my web.config, the global.asax code was called again.
The reason is a bit confusing to understand at first. In IIS7 integrated mode, http modules are treated as being part of IIS, be it that they are managed or not. This means that a module may or may not rely on asp.net. Your module will be executed but your web app won’t necessarily have been compiled. Handlers on the other hand, when they are managed, trigger the asp.net application, and your code will get executed.
So to conclude this issue that i’ve been chasing for two months now: if you don’t have a managed http handler for your request, your http module will be called but the asp.net part of your site will not have been compiled and / or won’t be called, including global.asax. The solution is to ensure you have a managed handler in place, or force a compilation of the root site using BuildManager.GetReferencedAssemblies.
P.S.: this is all based on empirical evidence, so I may be absolutely wrong, and would be glad for anyone to come up with an alternative explanation.