Understanding the Application Life Cycle

The life cycle of an ASP.NET application begins the moment the application is started and continues while HTTP requests are received from clients and processed to generate responses. It includes matching requests to controllers and actions and rendering content from Razor views. The life cycle ends when the application is stopped.

The ASP.NET platform provides notifications of the two stages of the life cycle through methods defined by the global application class. The global application class has been around since the earliest versions of ASP.NET and consists of two files: Global.asax and Global.asax.cs.

Strictly speaking, the Global.asax file is the global application class, and the Global.asax.cs file is the associated code-behind file. This is the classic Web Forms approach to splitting declarative and programmatic code and is an artifact of the origins of ASP.NET. The Global.asax file used to be more important in ASP.NET applications, but it is just there for compatibility these days, even in Web Forms projects. Listing 3-1 shows the content of the Global.asax file from the example project, although you will never need to edit this file for an MVC framework project.

Listing 3-1.  The Contents of the Global.asax File

<%@ Application Codebehind="Global.asax.cs" Inherits="SimpleApp.MvcApplication" Language="C#" %>

This is an example of a Web Forms directive that tells ASP.NET that the associated code file is called Global.asax.cs and that it is written in C#. (Remember that ASP.NET applications can be written in any .NET language and that Visual Basic is still widely used.)

The Global.asax file may be a mildly interesting artifact left over from earlier versions of ASP.NET, but for this chapter it is the Global.asax.cs file that is important. The role of these files has gradually changed as ASP.NET has matured, and now the term global application class is usually used to refer to the Global.asax.cs file to the extent that when you double-click Global.asax in the Solution Explorer, it is the Global.asax.cs file that opens in the editor.

Listing 3-2 shows the contents of the Global.asax.cs file that Visual Studio created for the example project.

Listing 3-2.  The Contents of the Global.asax.cs File

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Web.Routing;
 
namespace SimpleApp {
    public class MvcApplication : System.Web.HttpApplication {
        protected void Application_Start() {
            AreaRegistration.RegisterAllAreas();
            RouteConfig.RegisterRoutes(RouteTable.Routes);
        }
    }
}

The default global application class is called MvcApplication and is derived from the System.Web.HttpApplication class. You’ll see many more classes from the System.Web namespace in this book because it is the home of the bulk of the ASP.NET platform functionality.

The MvcApplication class is instantiated by the ASP.NET framework, and the methods it defines are called at key moments in the application life cycle (and, as you’ll learn, in the request life cycle).

The default implementation of the MvcApplication class contains only one method, called Application_Start, but there is another method available, and I describe them both in the following sections.

Receiving Notifications When the Application Starts and Ends

The global application class supports two special methods that define the start and end of the application life cycle, as described by Table 3-3.

The Application_Start method is called when the application is first started and provides an opportunity to perform one-off configuration tasks that affect the entire application. In Listing 3-2, you can see that Visual Studio has added statements to the Application_Start method that set up MVC areas and URL routes. When I created the example project in Chapter 2, I selected the option for the minimal initial project content, but additional statements would have been added to the Application_Start method if I had selected one of the other template options.

The Application_End method is called just before the application is terminated and is an opportunity to release any resources that the application maintains and to generally tidy up. The usual reason given for using this method is to release persistent database connections, but most modern web applications don’t manage connections directly, and I rarely find it necessary to implement the Application_End method in my own projects. Databases are pretty good at managing their own connections these days, which is good because the Application_End method is called only when the application is shut down in an orderly manner. You can’t rely on the method being called if the server fails or there is some other kind of sudden, unexpected problem such as a power outage.

I refer to these methods as being special because they are implemented in an odd way. These methods are not defined by the base for the global application class (which is System.Web.HttpApplication), so you don’t have to use the override keyword to implement them. In fact, the ASP.NET framework uses reflection to look for the methods by name. You won’t receive an error if you mistype the method names; ASP.NET just assumes you don’t want to be notified when the application starts or stops. For this reason, it is important to ensure that you test that your code is being called, which I demonstrate later in this chapter.

Calls to the Application_Start and Application_End methods bookend the life cycle of the application, and between those method calls ASP.NET receives and processes requests, as described in Figure 3-1. I’ll return to this diagram as I detail the request life cycle and show you how everything fits together.

Testing the Start and Stop Notifications

You can use the Application_Start and Application_End methods directly in your applications to perform one-off startup and shutdown activities, just as the MVC framework does. In this section, I’ll show you how to use the debugger to ensure that the methods are being called—something that is important when your custom code doesn’t work the way you expect.

The simplest way to check that these methods are being called is to use the Visual Studio debugger. In Listing 3-3 you can see how I have added calls to the static System.Diagnostics.Debugger.Break method to the Application_Start and Application_End methods, which has the same effect as setting a breakpoint using the Visual Studio code editor, but with the benefit of ensuring that you will get the same result I describe here if you re-create this example.

Listing 3-3.  Breaking the Debugger in the Global.asax.cs File

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Web.Routing;
 
namespace SimpleApp {
    public class MvcApplication : System.Web.HttpApplication {
 
        protected void Application_Start() {
            AreaRegistration.RegisterAllAreas();
            RouteConfig.RegisterRoutes(RouteTable.Routes);
            System.Diagnostics.Debugger.Break();
        }
 
        protected void Application_End() {
            System.Diagnostics.Debugger.Break();
        }
    }
}

I have added a call to the Break method in the existing Application_Start method and added the Application_End method (which contains only a call to Break since my application doesn’t have any cleanup code and none is required by the MVC framework).

Understanding the Request Life Cycle

The Application_Start and Application_End methods are not called on the MvcApplication instances that ASP.NET creates to handle requests. Instead, the ASP.NET framework triggers the sequence of events described in Table 3-5. These events describe the request life cycle.

The ASP.NET framework triggers these events to chart the path of a request through the processing life cycle. You can handle these events in the global application class, in a module, or in a handler. I introduce modules and handlers in the following section and describe them in depth in Chapters 4 and 5.

Understanding Modules and Handlers

In the following sections, I show you how to respond to the request life-cycle events directly in the global application class. This is a good start for exploring the life-cycle events, but it is suitable for only the simplest of interactions with requests. Any serious request handling functionality tends to consume a number of life-cycle events, which means that the global application class quickly becomes a morass of code that handles the same events to handle requests in different ways. The ASP.NET framework deals with this by supporting modules, which are self-contained classes that receive the life-cycle events and can monitor and manipulate requests. Many of the most important ASP.NET platform services rely on the module functionality to prepare a request early in its life cycle. Examples are the state data and security services, which include modules that respond to events such as AcquireRequestState and AuthenticateRequest to add data to a request before it is handled by the MVC framework. Modules can interact with requests—and the associated responses—at any point in the life cycle, and I describe them in detail in Chapter 4.

The ASP.NET framework also supports a component called a handler. Handlers are responsible for generating a response for a request. The handler for the MVC framework is the component responsible for locating a controller and action method to service a request and rendering the view that the action method specifies. The ASP.NET framework supports multiple handlers, which is why it is possible to mix and match development frameworks such as MVC, Web API, and Web Forms within the same application. The handler is linked to four of the request life-cycle events. The MapRequestHandler and PostMapRequestHandler events are triggered before and after a handler is selected for the request, and the PreRequestHandlerExecute and PostRequestHandlerExecute events are triggered before and after the handler is asked to generate a response for the request. I describe how handlers work in detail in Chapter 5.

The reason that I have introduced modules and handlers in this chapter is because doing so allows me to illustrate the request life cycle more completely, as shown in Figure 3-5.

Don’t worry if this seems complex; it will start to make sense as I explain how these events are handled and as you see how various ASP.NET platform services are implemented.

Notice that the global application class is instantiated by both the application and request life cycles. Not only does the ASP.NET framework create multiple instances to service parallel requests, but it also creates separate instances to support each life cycle. You will see the practical impact of this in the “Handling Property Exceptions” section later in this chapter.

Handling Request Life-Cycle Events Using Special Methods

To handle these events in the global application class, you create a method with a name that starts with Application_, followed by the event name, such as Application_BeginRequest, for example. As with the Application_Start and Application_End methods, the ASP.NET framework finds the methods and invokes them when the event they correspond to is triggered. In Listing 3-4, you can see how I have updated the global application class so it handles some of the events in the table (and removed the statements that cause the debugger to break).

Listing 3-4.  Handling Request life-Cycle Events in the Global.asax.cs File

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Web.Routing;
 
namespace SimpleApp {
    public class MvcApplication : System.Web.HttpApplication {
 
        protected void Application_Start() {
            AreaRegistration.RegisterAllAreas();
            RouteConfig.RegisterRoutes(RouteTable.Routes);
        }
 
        protected void Application_BeginRequest() {
            RecordEvent("BeginRequest");
        }
 
        protected void Application_AuthenticateRequest() {
            RecordEvent("AuthenticateRequest");
        }
 
        protected void Application_PostAuthenticateRequest() {
            RecordEvent("PostAuthenticateRequest");
        }
 
        private void RecordEvent(string name) {
            List<string> eventList = Application["events"] as List<string>;
            if (eventList == null) {
                Application["events"] = eventList = new List<string>();
            }
            eventList.Add(name);
        }
    }
}

I have defined a method called RecordEvent that accepts the name of an event and stores it using one of the ASP.NET state management features. I describe these features in detail in Chapter 10, but the one I have used in this example—accessed via the Application property of the HttpApplication class—stores data in a way that makes it available throughout the application.

I call the RecordEvent method from three other methods I added to the global application class. These events will be called when the BeginRequest, AuthenticateRequest, and PostAuthenticateRequest events are triggered. I don’t have to explicitly register these methods as event handlers; the ASP.NET framework locates and invokes these methods automatically.

using System.Web.Mvc;
using SimpleApp.Models;
 
namespace SimpleApp.Controllers {
    public class HomeController : Controller {
 
        public ActionResult Index() {
            return View(HttpContext.Application["events"]);
        }
 
        [HttpPost]
        public ActionResult Index(Color color) {
            Color? oldColor = Session["color"] as Color?;
            if (oldColor != null) {
                Votes.ChangeVote(color, (Color)oldColor);
            } else {
                Votes.RecordVote(color);
            }
            ViewBag.SelectedColor = Session["color"] = color;
            return View(HttpContext.Application["events"]);
        }
    }
}

@using SimpleApp.Models
@model List<string>
@{ Layout = null; }
 
<!DOCTYPE html>
<html>
<head>
    <meta name="viewport" content="width=device-width" />
    <title>Vote</title>
    <link href="∼/Content/bootstrap.min.css" rel="stylesheet" />
    <link href="∼/Content/bootstrap-theme.min.css" rel="stylesheet" />
</head>
<body class="container">
    <div class="panel panel-primary">
        @if (ViewBag.SelectedColor == null) {
            <h4 class="panel-heading">Vote for your favorite color</h4>
        } else {
            <h4 class="panel-heading">Change your vote from @ViewBag.SelectedColor</h4>
        }
 
        <div class="panel-body">
 
            @using (Html.BeginForm()) {
                @Html.DropDownList("color",
                        new SelectList(Enum.GetValues(typeof(Color))), "Choose a Color",
                            new { @class = "form-control" })
                <div>
                    <button class="btn btn-primary center-block"
                            type="submit">
                        Vote
                    </button>
                </div>
            }
 
        </div>
    </div>
 
    <div class="panel panel-primary">
        <h5 class="panel-heading">Results</h5>
        <table class="table table-condensed table-striped">
            @foreach (Color c in Enum.GetValues(typeof(Color))) {
                <tr><td>@c</td><td>@Votes.GetVotes(c)</td></tr>
            }
        </table>
    </div>
 
    <div class="panel panel-primary">
        <h5 class="panel-heading">Events</h5>
        <table class="table table-condensed table-striped">
            @foreach (string eventName in Model) {
                <tr><td>@eventName</td></tr>
            }
        </table>
    </div>
</body>
</html>

Handling Request Life-Cycle Events Without Special Methods

The HttpApplication class, which is the base for the global application class, defines regular C# events that can be used instead of special methods, as shown in Listing 3-7. The choice between the standard C# events and the special methods is a personal one, and you can mix and match techniques if you want.

Listing 3-7.  Using C# Events in the Global.asax.cs File

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Web.Routing;
 
namespace SimpleApp {
    public class MvcApplication : System.Web.HttpApplication {
 
        public MvcApplication() {
            BeginRequest += (src, args) => RecordEvent("BeginRequest");
            AuthenticateRequest += (src, args) => RecordEvent("AuthentucateRequest");
            PostAuthenticateRequest += (src, args) =>
                RecordEvent("PostAuthenticateRequest");
        }
 
        protected void Application_Start() {
            AreaRegistration.RegisterAllAreas();
            RouteConfig.RegisterRoutes(RouteTable.Routes);
        }
 
        private void RecordEvent(string name) {
            List<string> eventList = Application["events"] as List<string>;
            if (eventList == null) {
                Application["events"] = eventList = new List<string>();
            }
            eventList.Add(name);
        }
    }
}

I have added a constructor to the MvcApplication class and have used it to set up event handlers for three of the request life-cycle events. For all three events I have used lambda expressions that call the RecordEvent method, storing the name of the event so that it can be read back by the controller, just as in the previous example.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Web.Routing;
 
namespace SimpleApp {
    public class MvcApplication : System.Web.HttpApplication {
 
        public MvcApplication() {
            BeginRequest += RecordEvent;
            AuthenticateRequest += RecordEvent;
            PostAuthenticateRequest += RecordEvent;
        }
 
        protected void Application_Start() {
            AreaRegistration.RegisterAllAreas();
            RouteConfig.RegisterRoutes(RouteTable.Routes);
        }
 
        private void RecordEvent(object src, EventArgs args) {
            List<string> eventList = Application["events"] as List<string>;
            if (eventList == null) {
                Application["events"] = eventList = new List<string>();
            }
            string name = Context.CurrentNotification.ToString();
            if (Context.IsPostNotification) {
                name = "Post" + name;
            }
            eventList.Add(name);
        }
    }
}

Understanding the ASP.NET Context Objects

The class at the heart of the context is System.Web.HttpContext. It is universally available throughout the ASP.NET framework and the MVC framework, and it acts as a gateway to other context objects and to ASP.NET platform features and services. In fact, the HttpContext class is so central to the ASP.NET framework that the most important properties are like a map to the rest of this book, as Table 3-9 illustrates.

The HttpContext class also defines methods and properties that can be used to manage the request life cycle—like the CurrentNotification and IsPostNotification properties I used when handling life-cycle events with a single method in the previous section. I’ll show you the different context object features, including those defined by HttpContext, in the chapters that are related to their functionality.

As you saw in Listing 3-8, you can get an instance of the HttpContext class using the Context property from within the global application class. This property name is not universal; you will need to use the HttpContext property from within a controller class or a view, for example. If all else fails, you can get the HttpContext object associated with the current request by using the static HttpContext.Current property. For quick reference, Table 3-10 summarizes the ways in which you can get an HttpContext object in the different parts of an application.

Notice that I have not included the model in the list of application components in Table 3-10. You can obtain the HttpContext object for the current request in the model through the static HttpContext.Current property, but I suggest that you don’t because it blurs the separation of concerns between the model and the controller. If the model needs information about a request, then obtain this information from the context objects in the controller and pass it as method arguments to the model. This will ensure that the model doesn’t meddle in the business of controllers and will allow the model to be unit tested without any reference to ASP.NET or the MVC framework.

Working with HttpApplication Objects

Many of the classes that you will use in the ASP.NET framework provide convenience properties that are mapped to those defined by the HttpContext class. A good example of this overlap can be seen in HttpApplication, which is the base for the global application class. In Table 3-11, you can see the properties and methods defined by the HttpApplication class, many of which are similar to those defined by HttpContext.

Most of these members are convenience properties that map to the properties of the HttpContext class, but there are some points to note, as discussed in the following section.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Web.Routing;
 
namespace SimpleApp {
    public class MvcApplication : System.Web.HttpApplication {
 
        public MvcApplication() {
            PostAcquireRequestState += (src, args) => CreateTimeStamp();
        }
 
        protected void Application_Start() {
            AreaRegistration.RegisterAllAreas();
            RouteConfig.RegisterRoutes(RouteTable.Routes);
            CreateTimeStamp();
        }
 
        private void CreateTimeStamp() {
            string stamp = Context.Timestamp.ToLongTimeString();
            if (Session != null) {
                Session["request_timestamp"] = stamp;
            } else {
                Application["app_timestamp"] = stamp;
            }
        }
    }
}

...
private void CreateTimeStamp() {
    string stamp = Context.Timestamp.ToLongTimeString();
    if (Context.Session != null) {
        Session["request_timestamp"] = stamp;
    } else {
        Application["app_timestamp"] = stamp;
    }
}
...

using System.Collections.Generic;
using System.Web.Mvc;
using SimpleApp.Models;
 
namespace SimpleApp.Controllers {
    public class HomeController : Controller {
 
        public ActionResult Index() {
            return View(GetTimeStamps());
        }
 
        [HttpPost]
        public ActionResult Index(Color color) {
            Color? oldColor = Session["color"] as Color?;
            if (oldColor != null) {
                Votes.ChangeVote(color, (Color)oldColor);
            } else {
                Votes.RecordVote(color);
            }
            ViewBag.SelectedColor = Session["color"] = color;
            return View(GetTimeStamps());
        }
 
        private List<string> GetTimeStamps() {
            return new List<string> {
                string.Format("App timestamp: {0}",
                    HttpContext.Application["app_timestamp"]),
                string.Format("Request timestamp: {0}", Session["request_timestamp"]),
            };
        }
    }
}

Working with HttpRequest Objects

The HttpRequest object describes a single HTTP request as it is being processed. Table 3-12 describes the HttpRequest properties that provide information about the current request. (The HttpRequest class defines methods and some other properties, but I describe these in later chapters in the context of the platform features they correspond to.)

To demonstrate the use of the HttpRequest class, I have modified the Index.cshtml view so that it displays some of the request properties, as shown in Listing 3-12.

Listing 3-12.  Displaying Request Details in the Index.cshtml File

@using SimpleApp.Models
@model List<string>
@{ Layout = null; }
 
<!DOCTYPE html>
<html>
<head>
    <meta name="viewport" content="width=device-width" />
    <title>Vote</title>
    <link href="∼/Content/bootstrap.min.css" rel="stylesheet" />
    <link href="∼/Content/bootstrap-theme.min.css" rel="stylesheet" />
</head>
<body class="container">
    <div class="panel panel-primary">
        @if (ViewBag.SelectedColor == null) {
            <h4 class="panel-heading">Vote for your favorite color</h4>
        } else {
            <h4 class="panel-heading">Change your vote from @ViewBag.SelectedColor</h4>
        }
 
        <div class="panel-body">
 
            @using (Html.BeginForm()) {
                @Html.DropDownList("color",
                        new SelectList(Enum.GetValues(typeof(Color))), "Choose a Color",
                            new { @class = "form-control" })
                <div>
                    <button class="btn btn-primary center-block"
                            type="submit">
                        Vote
                    </button>
                </div>
            }
 
        </div>
    </div>
 
    <div class="panel panel-primary">
        <h5 class="panel-heading">Results</h5>
        <table class="table table-condensed table-striped">
            @foreach (Color c in Enum.GetValues(typeof(Color))) {
                <tr><td>@c</td><td>@Votes.GetVotes(c)</td></tr>
            }
        </table>
    </div>
 
    <div class="panel panel-primary">
        <h5 class="panel-heading">Request Properties</h5>
        <table class="table table-condensed table-striped">
            <tr><th>Property</th><th>Value</th></tr>
            <tr><td>HttpMethod</td><td>@Request.HttpMethod</td></tr>
            <tr><td>IsLocal</td><td>@Request.IsLocal</td></tr>
            <tr><td>RawURL</td><td>@Request.RawUrl</td></tr>
        </table>
    </div>
</body>
</html>

Notice that I am able to access the HttpRequest object using a property called Request, like this:

...
<tr><td>HttpMethod</td><td>@Request.HttpMethod</td></tr>
...

The HttpRequest object is so frequently used that some application components, including Razor views, provide convenience properties so that you don’t have to obtain an HttpContext object just to get an instance of HttpRequest. Table 3-13 summarizes the convenience properties that are available for HttpRequest objects.

Figure 3-8 shows the request property values displayed by the view, for both an initial GET request and the POST request that results when the user selects a color and clicks the Vote button.

In addition to the properties shown in Table 3-12, there are some properties that provide access to the data included in a request. I have shown these in Table 3-14, but they are not usually used directly in MVC controllers because model binding, which I describe in Pro ASP.NET MVC 5, is easier to work with. These properties are sometimes used in modules, however.

Working with HttpResponse Objects

The HttpResponse object is the counterpart to HttpRequest and represents the response as it is being constructed. It also provides methods and properties that let you customize the response, something that is rarely required when using MVC views but that can be useful when working with other components, such as modules and handlers (described in Chapters 4 and 5).

Like HttpRequest, this class is essential to the way that ASP.NET processes requests and is used extensively within the MVC framework to generate the HTML (or other data) that is returned to clients. I have described the most important methods and properties in Table 3-15.

In Table 3-16, I have summarized the convenience properties for a range of ASP.NET and MVC framework components.