Dotnet Library: First Program on ASP and Execution Life Cycle

First ASP.NET Program:

Now let us have our First ASP.NET program.

Let’s look at both the markup and the C# portions of a simple web forms application that generates a movie line-up dynamically through software.

Markup Portion

Web form application part 1 -- SimpleWebForm.aspx

<% @Page Language="C#" Inherits="MoviePage" Src="SimpleWebForm.cs" %> 

<html>
<body background="Texture.bmp">

<TITLE>Supermegacineplexadrome!</TITLE>

<H1 align="center"><FONT color="white" size="7">Welcome to <br>Supermegacineplexadrome!</FONT></H1>

<P align="left"><FONT color="lime" size="5"><STRONG>

<U>Showtimes for <%WriteDate();%></U>

</STRONG></FONT></P>

<FONT size="5" color="yellow"><%WriteMovies();%></FONT>

</body>
</html>

And this is where the C# part of a web forms application comes in.

Web form application part 2 - SimpleWebForm.cs

using System;
using System.Web.UI;
using System.Web.UI.WebControls;

public class MoviePage:Page 
{
    protected void WriteDate()
    {
        Response.Write(DateTime.Now.ToString());
    }

    protected void WriteMovies()
    {
        Response.Write("<P>The Glass Ghost (R) 1:05 pm, 3:25 pm, 7:00 pm</P>");
        Response.Write("<P>Untamed Harmony (PG-13) 12:50 pm, 3:25 pm, " + <br>                       "6:55 pm</P>");
        Response.Write("<P>Forever Nowhere (PG) 3:30 pm, 8:35 pm</P>");
        Response.Write("<P>Without Justice (R) 12:45 pm, 6:45 pm</P>");
    }
}

Execution Cycle :

Now let's see what’s happening on the server side. You will shortly understand how server controls fit in.

A request for an .aspx file causes the ASP.NET runtime to parse the file for code that can be compiled. It then generates a page class that instantiates and populates a tree of server control instances. This page class represents the ASP.NET page.

Now an execution sequence is started in which, for example, the ASP.NET page walks its entire list of controls, asking each one to render itself.

The controls paint themselves to the page. This means they make themselves visible by generating HTML output to the browser client.

Execution Process

We need to have a look at what’s happening to your code in ASP.NET.

Compilation, when page is requested the first time

The first time a page is requested, the code is compiled. Compiling code in .NET means that a compiler in a first step emits Microsoft intermediate language (MSIL) and produces metadata—if you compile your source code to managed code. In a following step MSIL has to be converted to native code.

Microsoft intermediate language (MSIL)

Microsoft intermediate language is code in an assembly language–like style. It is CPU independent and therefore can be efficiently converted to native code.

The conversion in turn can be CPU-specific and optimized. The intermediate language provides a hardware abstraction layer.

MSIL is executed by the common language runtime.

Common language runtime

The common language runtime contains just-in-time (JIT) compilers to convert the MSIL into native code. This is done on the same computer architecture that the code should run on.

The runtime manages the code when it is compiled into MSIL—the code is therefore called managed code.

ASP.NET Applications and Configuration

Overview

Like ASP, ASP.NET encapsulates its entities within a web application. A web application is an abstract term for all the resources available within the confines of an IIS virtual directory. For example, a web application may consist of one or more ASP.NET pages, assemblies, web services configuration files, graphics, and more. In this section we explore two fundamental components of a web application, namely global application files (Global.asax) and configuration files (Web.config).

Global.asax

Global.asax is a file used to declare application-level events and objects. Global.asax is the ASP.NET extension of the ASP Global.asa file. Code to handle application events (such as the start and end of an application) reside in Global.asax. Such event code cannot reside in the ASP.NET page or web service code itself, since during the start or end of the application, its code has not yet been loaded (or unloaded). Global.asax is also used to declare data that is available across different application requests or across different browser sessions. This process is known as application and session state management.

The Global.asax file must reside in the IIS virtual root. Remember that a virtual root can be thought of as the container of a web application. Events and state specified in the global file are then applied to all resources housed within the web application. If, for example, Global.asax defines a state application variable, all .aspx files within the virtual root will be able to access the variable.

Like an ASP.NET page, the Global.asax file is compiled upon the arrival of the first request for any resource in the application. The similarity continues when changes are made to the Global.asax file; ASP.NET automatically notices the changes, recompiles the file, and directs all new requests to the newest compilation. A Global.asax file is automatically created when you create a new web application project in the VS.NET IDE.

Application Directives

Application directives are placed at the top of the Global.asax file and provide information used to compile the global file. Three application directives are defined, namely Application, Assembly, and Import. Each directive is applied with the following syntax:

 <%@ appDirective appAttribute=Value ...%>

Web.config

In ASP, configuration settings for an application (such as session state) are stored in the IIS metabase. There are two major disadvantages with this scheme. First, settings are not stored in a human-readable manner but in a proprietary, binary format. Second, the settings are not easily ported from one host machine to another.(It is difficult to transfer information from an IIS’s metabase or Windows Registry to another machine, even if it has the same version of Windows.)

Web.config solves both of the aforementioned issues by storing configuration information as XML. Unlike Registry or metabase entries, XML documents are human-readable and can be modified with any text editor. Second, XML files are far more portable, involving a simple file transfer to switch machines.

Unlike Global.asax, Web.config can reside in any directory, which may or may not be a virtual root. The Web.config settings are then applied to all resources accessed within that directory, as well as its subdirectories. One consequence is that an IIS instance may have many web.config files. Attributes are applied in a hierarchical fashion. In other words, the web.config file at the lowest level directory is used.

Since Web.config is based on XML, it is extensible and flexible for a wide variety of applications. It is important, however, to note that the Web.config file is optional. A default Web.config file, used by all ASP.NET application resources, can be found on the local machine at:

\%winroot%\Microsoft.Net\Framework\version\CONFIG\machine.config

Dotnet Library

Friday, 20 September 2013

First Program on ASP and Execution Life Cycle