This is actually possible, but it doesn’t involve the Global.asax file.
Many of Microsoft’s examples demonstrate wiring code in via the Global.asax, but this is not a best-practices approach when it comes to SharePoint. Ideally, your code should get packaged as a Feature and deployed via WSP (as you already know).
The key lies in implementing the code in question as an HttpModule (i.e., a type that implements the IHttpModule interface) and wiring it into the ASP.NET pipeline servicing your SharePoint application. Roughly speaking, these are the steps:
- Create a class that implements the IHttpModule interface.
- Implement the Init method in your HttpModule; this is called when the HttpApplication (in this case, the SPHttpApplication) is setup, and it gives you an opportunity to carry out processing, wire-up event delegates for other pipeline events, etc.
- Create an SPFeatureReceiver that will add and remove your HttpModule from target web.config files on activation and deactivation, respectively. This is carried out using the SPWebConfigModification type to update the <httpModules> node in target web.config files.
- Package all as a Feature and deploy via WSP.
For more information on HttpModule development, see http://msdn.microsoft.com/en-us/library/ms227673.aspx. For some additional detail on the SPWebConfigModification type, see http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebconfigmodification.aspx.
Result: a class that can handle application startup and is deployable via Feature. No manual file hacking required.
I’ve successfully used this in a number of scenarios — most recently with a custom caching provider (IVaryByCustomHandler) that needed to register itself for callbacks with the SPHttpApplication when it started.
Though your question is a bit older, I hope this helps!
My gut feeling on this is that it won’t be possible. Application_Start is called by the runtime as the asp.net engine is starting up, so there most likely can’t be any way to hook the handler outside of modifying the Global.asax – e.g. the hook must be declarative and persistent as it has to survive the application stopping/unloading. So, if you have to write to the global.asax, I guess you could write a Feature EventReceiver to perform the modification.
That aside, can you give more details on the why? Perhaps there are other angles of attack. The idea of modifying the global.asax on the fly makes me feel ill. That can’t be good.