Global.asax, Keeping the Magic Alive

In my efforts to retrofit an old Sitecore Web Forms application for caching which is safe for use with postback, etc. in an elegant way, I needed to review the full set of “magic” methods available in the Global.asax application file, which ASP.NET wires up at runtime.

As a reminder, make sure that you’ve included a script runat=”server” tag enclosing your code–you may have to restore this if deleted from, or never added to, an empty file. Confusion abounds on the web as to whether Global.asax works with ASP.NET MVC (it does), primarily because of this missing script tag.

The application- and session-specific event methods are:

Application_Start
Application_End
Application_Error
Session_Start
Session_End

The request-specific events are:

Application_BeginRequest
Application_AuthenticateRequest
Application_AuthorizeRequest
Application_ResolveRequestCache
Application_AcquireRequestState
Application_PreRequestHandlerExecute
Application_PreSendRequestHeaders
Application_PreSendRequestContent
Application_PostRequestHandlerExecute
Application_ReleaseRequestState
Application_UpdateRequestCache
Application_EndRequest

Sources:
https://web.archive.org/web/20071223170129/http://articles.techrepublic.com.com/5100-10878_11-5771721.html
http://sandblogaspnet.blogspot.com/2008/03/methods-in-globalasax.html

Advertisements

How to use the File Explorer and XPath Builder in Sitecore 8.1

New: Dynamically evaluate C# expressions and execute C# scripts with a single statement, from anywhere in a .NET application. Click here for more info.

Later versions of Sitecore don’t provide an easy way to launch the Sitecore File Explorer and XPath Builder from the web, but they’re still there. In order to use them, go directly to the following URLs on your instance, and enjoy.

/sitecore/shell/default.aspx?xmlcontrol=FileExplorer
/sitecore/shell/default.aspx?xmlcontrol=IDE

Use ASP.NET output caching safely with post-back

The venerable ASP.NET output caching mechanism is useful for caching HTML fragments generated by controls. This can have a massive impact on performance and scalability of sites, but the implementation is not without drawbacks. One common problem encountered with web forms is how to use output caching, but disable it for post-back or similar scenarios. This can be important, for example, in presenting paged search results, where it can be advantageous to cache the first page of results but users may less frequently go to the second page.

In order to do this, override the GetVaryByCustomString method in Global.asax as follows:

  /// <summary>
  /// Added to support control output caching, varying by URL. 
  /// </summary>
  public override string GetVaryByCustomString(HttpContext context, string custom)
  {
	  switch (custom.ToUpper())
	  {
		  case "RAWURL":
			  {

				  if (context.Request.RequestType.Equals("POST"))
				  {
					  context.Response.Cache.SetNoServerCaching();

					  return "POST " + DateTime.Now.Ticks + " " + context.Request.RawUrl;
				  }
				  else 
					  return context.Request.RawUrl;
			  }
		  default:
			  return "";
	  }
  }

Then, on any control for which you wish to enable output caching but only if the page load is not a post-back, add the following directive:

<%@outputcache duration=”3600″ varybyparam=”none” varybycustom=”RAWURL” %>

Note that the ‘duration’ value is in seconds, and set it accordingly. Obviously the ‘varybycustom’ value can be set to any value desired, as long as it is trapped appropriately in GetVaryByCustomString().

One can easily combine this approach with one sensitive to different cookies as well (one example). One could similarly key off of page-level variables stored in view state, application state variables, etc.; the name of the variable by which to vary may for example be stuffed, with an appropriate prefix, into ‘varybycustom’ in the directive. Strategies like these can be used to achieve a range of different effects, for instance to use output caching safely with paging.