ASP.NET Application Life Cycle Overview for IIS 5.0 and 6.0

Within ASP.NET, several processing steps must occur for an ASP.NET application to be initialized and process requests. Additionally, ASP.NET is only one piece of the Web server architecture that services requests made by browsers. It is important for you to understand the application life cycle so that you can write code at the appropriate life cycle stage for the effect you intend.

Application Life Cycle in General
User requests an application resource from the Web server. The life cycle of an ASP.NET application starts with a request sent by a browser to the Web server (for ASP.NET applications, typically IIS). ASP.NET is an ISAPI extension under the Web server. When a Web server receives a request, it examines the file-name extension of the requested file, determines which ISAPI extension should handle the request, and then passes the request to the appropriate ISAPI extension. ASP.NET handles file name extensions that have been mapped to it, such as .aspx, .ascx, .ashx, and .asmx. If a file name extension has not been mapped to ASP.NET, ASP.NET will not receive the request. This is important to understand for applications that use ASP.NET authentication. For example, because .htm files are typically not mapped to ASP.NET, ASP.NET will not perform authentication or authorization checks on requests for .htm files. Therefore, even if a file contains only static content, if you want ASP.NET to check authentication, create the file using a file name extension mapped to ASP.NET, such as .aspx. If you create a custom handler to service a particular file name extension, you must map the extension to ASP.NET in IIS and also register the handler in your application’s Web.config file.

ASP.NET receives the first request for the application. When ASP.NET receives the first request for any resource in an application, a class named ApplicationManager creates an application domain. Application domains provide isolation between applications for global variables and allow each application to be unloaded separately. Within an application domain, an instance of the class named HostingEnvironment is created, which provides access to information about the application such as the name of the folder where the application is stored. ASP.NET also compiles the top-level items in the application if required, including application code in the App_Code folder.


ASP.NET core objects are created for each request. After the application domain has been created and the HostingEnvironment object instantiated, ASP.NET creates and initializes core objects such as HttpContext, HttpRequest, and HttpResponse. The HttpContext class contains objects that are specific to the current application request, such as the HttpRequest and HttpResponse objects. The HttpRequest object contains information about the current request, including cookies and browser information. The HttpResponse object contains the response that is sent to the client, including all rendered output and cookies.

An HttpApplication object is assigned to the request. After all core application objects have been initialized, the application is started by creating an instance of the HttpApplication class. If the application has a Global.asax file, ASP.NET instead creates an instance of the Global.asax class that is derived from the HttpApplication class and uses the derived class to represent the application. The first time an ASP.NET page or process is requested in an application, a new instance of HttpApplication is created. However, to maximize performance, HttpApplication instances might be reused for multiple requests.
When an instance of HttpApplication is created, any configured modules are also created. For instance, if the application is configured to do so, ASP.NET creates a SessionStateModule module. After all configured modules are created, the HttpApplication class’s Init method is called.


The request is processed by the HttpApplication pipeline. The following events are executed by the HttpApplication class while the request is processed. The events are of particular interest to developers who want to extend the HttpApplication class.

  1. Validate the request, which examines the information sent by the browser and determines whether it contains potentially malicious markup. For more information, see ValidateRequest and Script Exploits Overview.
  2. Perform URL mapping, if any URLs have been configured in the UrlMappingsSection section of the Web.config file.
  3. Raise the BeginRequest event.
  4. Raise the AuthenticateRequest event.
  5. Raise the PostAuthenticateRequest event.
  6. Raise the AuthorizeRequest event.
  7. Raise the PostAuthorizeRequest event.
  8. Raise the ResolveRequestCache event.
  9. Raise the PostResolveRequestCache event.
  10. Based on the file name extension of the requested resource (mapped in the application’s configuration file), select a class that implements IHttpHandler to process the request. If the request is for an object (page) derived from the Page class and the page needs to be compiled, ASP.NET compiles the page before creating an instance of it.
  11. Raise the PostMapRequestHandler event.
  12. Raise the AcquireRequestState event.
  13. Raise the PostAcquireRequestState event.
  14. Raise the PreRequestHandlerExecute event.
  15. Call the ProcessRequest method (or the asynchronous version IHttpAsyncHandler..::.BeginProcessRequest) of the appropriate IHttpHandler class for the request. For example, if the request is for a page, the current page instance handles the request.
  16. Raise the PostRequestHandlerExecute event.
  17. Raise the ReleaseRequestState event.
  18. Raise the PostReleaseRequestState event.
  19. Perform response filtering if the Filter property is defined.
  20. Raise the UpdateRequestCache event.
  21. Raise the PostUpdateRequestCache event.
  22. Raise the EndRequest event.
  23. Raise the PreSendRequestHeaders event.
  24. Raise the PreSendRequestContent event.

Life Cycle Events and the Global.asax file
During the application life cycle, the application raises events that you can handle and calls particular methods that you can override. To handle application events or methods, you can create a file named Global.asax in the root directory of your application.
If you create a Global.asax file, ASP.NET compiles it into a class derived from the HttpApplication class, and then uses the derived class to represent the application.
An instance of HttpApplication processes only one request at a time. This simplifies application event handling because you do not need to lock non-static members in the application class when you access them. This also allows you to store request-specific data in non-static members of the application class. For example, you can define a property in the Global.asax file and assign it a request-specific value.
ASP.NET automatically binds application events to handlers in the Global.asax file using the naming convention Application_event, such as Application_BeginRequest. This is similar to the way that ASP.NET page methods are automatically bound to events, such as the page’s Page_Load event. For details, see ASP.NET Page Life Cycle Overview.
The Application_Start and Application_End methods are special methods that do not represent HttpApplication events. ASP.NET calls them once for the lifetime of the application domain, not for each HttpApplication instance.


DLL versus EXE

The most important difference is that an EXE is a program that can be run by the user or by another program. When you run an EXE it loads it into memory and then loads any DLLs it uses and calls the EXE’s main procedure. Although EXEs and DLLs share the same format, the OS will not allow a DLL to be executed.
A DLL is not meant to be run. It is a library. It is a collection of procedures and data that can be used by other code modules (by EXEs and other DLLs).

Is the ordinary EXE same as static linked library ?
Not at all. An EXE is not a library in any sense. A library is a collect of code ot data that can be used by other code. An EXE cannot be used in this way. A DLL can, thus a DLL is a library, but not a static linked library.
A DLL is basically a repository for shared code. The benefit of using DLL’s is that if 8 programs (EXE’s) use the same function, with a DLL, the binary code is only loaded into memory once and all 8 programs attach to the DLL, so it reduces the memory footprint some. As an example, the common dialogs (File Open, File Save, etc.) reside in a DLL. If these were statically linked, each program would have its own copy of all of the common dialogs, and would increase its memory footprint accordingly.

An EXE is loading into memory when somone wants to run it. That could be the user, or another program. A DLL is loaded when an EXE or DLL is loaded that uses it (EXE when loaded with LoadLibrary). When the DLL is loaded it does not “run” like and EXE runs. It sort of just “sits there” and waits for other code modules to use the procedures and data it provides.

so where is the advantage ?
There is no advantage, they serve different purposes. The EXE is a program It is the ultimate goal of programming. it is something useful to the user. A DLL is a library that can be used to make useful EXEs but by themselves they are useless. In the end an EXE is necessary to make the the DLL do userful things.

(source: )

Static Typing vs Dynamic Typing

Static Typing
Static typed programming languages are those in which variables need not be defined before they’re used. This implies that static typing has to do with the explicit declaration (or initialization) of variables before they’re employed. Java is an example of a static typed language; C and C++ are also static typed languages. Note that in C (and C++ also), variables can be cast into other types, but they don’t get converted; you just read them assuming they are another type.
Static typing does not imply that you have to declare all the variables first, before you use them; variables maybe be initialized anywhere, but developers have to do so before they use those variables anywhere. Consider the following example:
/* C code */
static int num, sum; // explicit declaration
num = 5; // now use the variables
sum = 10;
sum = sum + num;

The above code fragment is an example of how variable declaration in static typed languages generally appears. Note that in the above code, static has nothing to do with static typing; it has been used along with int only to initialize num and sum to zero.

Dynamic Typing
Dynamic typed programming languages are those languages in which variables must necessarily be defined before they are used. This implies that dynamic typed languages do not require the explicit declaration of the variables before they’re used. Python is an example of a dynamic typed programming language, and so is PHP. Consider the following example:

/* Python code */
num = 10 // directly using the variable

In the above code fragment, we have directly assigned the variable num the value 10 before initializing it. This is characteristic to dynamic typed programming languages.

Another Analogy
A lot of people define static typing and dynamic typing with respect to the point at which the variable types are checked. Using this analogy, static typed languages are those in which type checking is done at compile-time, whereas dynamic typed languages are those in which type checking is done at run-time.
This analogy leads to the analogy we used above to define static and dynamic typing. I believe it is simpler to understand static and dynamic typing in terms of the need for the explicit declaration of variables, rather than as compile-time and run-time type checking.

source: Introduction to Static and Dynamic Typing

Strong-typing vs weak-typing

What is a “type”, anyway?
A type is metadata about a chunk of memory that classifies the kind of data stored there. This classification usually implicitly specifies what kinds of operations may be performed on the data.
Common types include primitive types (strings and numbers), container types (lists/arrays and dictionaries/hashes), and user-defined types (classes). In Python, everything is an object, and every object has a type. In other words, functions, modules, and stack frames are also types.

Weak typing is where a language allows you to treat blocks of memory defined as one type as another (casting). Languages like C and C++, although statically typed, are weakly typed.
Languages like Perl and PHP are weakly typed because you can do things like adding numbers to strings and the language will do an implicit coercion for you.
Languages like Java, C# and Python are strongly typed – there is no way you can add a number to a string without doing an explicit conversion.
In addition, there are many large systems that have been created with dynamic type systems. Catching type errors (typos) at compile time only catches a very small proportion of errors and a strong testing strategy produces much more reliable systems irrespective of the type system in use. (source:

Strong typing prevents mixing operations between mismatched types. In order to mix types, you must use an explicit conversion. Conversely, weak typing means that you can mix types without an explicit conversion (source:

.NET Framework

The Microsoft .NET Framework is a software framework that can be installed on computers running Microsoft Windows operating systems. It includes a large library of coded solutions to prevent common programming problems and a virtual machine that manages the execution of programs written specifically for the framework. The .NET Framework is a key Microsoft offering and is intended to be used by most new applications created for the Windows platform.

The framework’s Base Class Library provides a large range of features including user interface, data and data access, database connectivity, cryptography, web application development, numeric algorithms, and network communications. The class library is used by programmers, who combine it with their own code to produce applications.

Programs written for the .NET Framework execute in a software environment that manages the program’s runtime requirements. Also part of the .NET Framework, this runtime environment is known as the Common Language Runtime (CLR). The CLR provides the appearance of an application virtual machine so that programmers need not consider the capabilities of the specific CPU that will execute the program. The CLR also provides other important services such as security, memory management, and exception handling. The class library and the CLR together constitute the .NET Framework.

(source: Wikipedia )