Global.asax events and Sitecore pipelines

At Pentia we always try not to change any files that ships in an out-of-the-box Sitecore installation. This makes upgrading easier and the solution code more transparent for developers.

Sitecore ships with a standard Global.asax file and a lot of Sitecore developers choose to make changes directly in this to hook into application and session level events.

For example see the tutorial code from Glass Sitecore Mapper here the Global.asax is used to set the glass context on the Application_Start event.

This could be done in the Sitecore initialize pipeline instead of changing the Global.asax file. It would actually be nice to see the Glass example code moved to the initialize pipeline instead so it fully embraces the Sitecore API 🙂

I recently worked on a solution Pentia inherited from another Sitecore partner. This solution used the Global.asax to initialize IoC containers through some class on the Application_Start event as shown below.

The first thing I did when I saw that code was to move it to where I personally feel it belongs that is in a processor patched into the initialize pipeline. I still dislike their class name, Initializer, but that is something else.

Sitecore starts the initialize pipeline on Application_Start so there is nothing that you can do on the Global.asax Application_Start event that you cannot do in a processor in the initialize pipeline.

The same goes for the Application_End event and the shutdown pipeline. Anything you would like to do on Application_End can go in a processor in the shutdown pipeline.

The list below shows which Sitecore pipelines that can be used instead of Global.asax event handlers.

  • Application_Start <> initialize
  • Application_BeginRequest <> preprocessRequest / httpRequestBegin
  • Application_EndRequest <> httpRequestEnd
  • Session_End <> sessionEnd
  • Application_End <> shutdown

There is no pipeline for Application_Error but Sitecore logs these anyway so I very rarely see a valid reason for hooking into this event.

Why use the standard Sitecore pipelines?

Why not use Global.asax when we all know that it works fine.

It is of course a bit subjective but I prefer to fully embrace the Sitecore API and keep responsibility in one place only. So everything that happens when the application starts can be seen in the initialize pipeline, everything that happens when the application ends can be seen in the shutdown pipeline and so on. Please feel free to share your thoughts on this in the comments.

Anders Laub Christoffersen

Anders has been working with Sitecore for over a decade and has in this time been the lead developer and architect on several large scale enterprise solutions all around the world. Anders was appointed the title of Sitecore Technical MVP in 2014 and has been re-appointed the title every year since then.

8 thoughts on “Global.asax events and Sitecore pipelines

    • Hi Mike,

      Nice, exactly how it should be done 🙂

      I would guess that Sitecore starts the initialize pipeline from the Application_Start event in their base Sitecore.Web.Application which the Global.asax inherits from. I am not sure on this since the Nexus code is obfuscated.

      If this is true then i don’t see any case where you cant use an initialize pipeline processor instead of Global.asax.


  1. As a compliment to using the Sitecore pipelines for startup events I would also strongly recommend WebActivator that can be downloaded from Nuget. It offers a simple attribute based approach to mark methods that should be run at startup.

  2. Hi Anders,

    In which cases would you use a hook instead of an initialization pipeline? Wouldn’t IoC and other initialization code be a prime example of code that would fit into a Sitecore Hook? So instead of filling the initialization pipeline with small tasks you could isolate these to hooks.


    • Hi Jonas,

      I would use the initialize pipeline for everything that is crucial for the solution to run. For example IoC initialization.

      Hooks are in my view only meant for attaching lightweight code that the solution does not depend on. For example the memory monitor hook.


Leave a Reply

Your email address will not be published. Required fields are marked *