Overview of the ASP.NET Framework

Overview of the ASP.NET Framework
Let’s start by building a simple ASP.NET page.
For information on installing ASP.NET, see the last section of this chapter. If you are using Visual Web Developer or Visual Studio, you first need to create a new website. Start Visual Web Developer and select the menu option File, New Web Site. The New Web Site dialog box appears (see Figure 1.1). Enter the folder where you want your new website to be created in the Location field and click the OK button.

After you create a new website, you can add an ASP.NET page to it. Select the menu option Web Site, Add New Item. Select Web Form and enter the value FirstPage.aspx in the Name field. Make sure that both the Place Code in


Separate File and Select Master Page check boxes are unchecked, and click the Add button to create the new ASP.NET page (see Figure 1.2).






The ASP.NET page in Listing 1.1 displays a brief message and the server’s current date and time. You can view the page in Listing 1.1 in a browser by right-clicking the page and selecting View in Browser (see Figure 1.3).



The page in Listing 1.1 is an extremely simple page. However, it does illustrate the most common elements of an ASP.NET page. The page contains a directive, a code declaration block, and a page render block.
The first line, in Listing 1.1, contains a directive. It looks like this:

         <%@ Page Language=”C#” %>

A directive always begins with the special characters <%@ and ends with the characters %>. Directives are used primarily to provide the compiler with the information it needs to compile the page.
For example, the directive in Listing 1.1 indicates that the code contained in the page is C# code. The page is compiled by the C# compiler and not another compiler such as the Visual Basic .NET (VB.NET) compiler.

The next part of the page begins with the opening <script runat=”server”> tag and ends with the closing </script> tag. The <script> tag contains something called the code declaration block.

The code declaration block contains all the methods used in the page. It contains all the page’s functions and subroutines. The code declaration block in Listing 1.1 includes a single method named Page_Load(), which looks like this:
void Page_Load()
  {
lblServerTime.Text = DateTime.Now.ToString();
}

This method assigns the current date and time to the Text property of a Label control contained in the body of the page named lblServerTime. The Page_Load() method is an example of an event handler. This method handles the Page Load event. Each and every time the page loads, the method automatically executes and assigns the current date and time to the Label control.

The final part of the page is called the page render block. The page render block contains everything that is rendered to the browser. In Listing 1.1, the render block includes everything between the opening and closing <html> tags.

The majority of the page render block consists of everyday HTML. For example, the page contains the standard HTML <head> and <body> tags. In Listing 1.1, there are two special things contained in the page render block.

First, notice that the page contains a <form> tag that looks like this:
<form id=”form1” runat=”server”>

This is an example of an ASP.NET control. Because the tag includes a runat=”server” attribute, the tag represents an ASP.NET control that executes on the server.

ASP.NET pages are often called web form pages because they almost always contain a server-side form element.

The page render block also contains a Label control. The Label control is declared with the <asp:Label> tag. In Listing 1.1, the Label control is used to display the current date and time.

Controls are the heart of the ASP.NET framework. Most of the ink contained in this book is devoted to describing the properties and features of the ASP.NET controls.

Controls are discussed in more detail shortly. However, first you need to understand the .NET Framework.

ASP.NET and the .NET Framework
ASP.NET is part of the Microsoft .NET Framework. To build ASP.NET pages, you need to take advantage of the features of the .NET Framework. The .NET Framework consists of two parts: the Framework Class Library and the Common Language Runtime.

Understanding the Framework Class Library

The .NET Framework contains thousands of classes that you can use when building an application. The Framework Class Library was designed to make it easier to perform the most common programming tasks. Here are just a few examples of the classes in the framework:

File class—Enables you to represent a file on your hard drive. You can use the File class to check whether a file exists, create a new file, delete a file, and perform many other file-related tasks.
Graphics class—Enables you to work with different types of images such as GIF, PNG, BMP, and JPEG images. You can use the Graphics class to draw rectangles, arcs, ellipsis, and other elements on an image.
Random class—Enables you to generate a random number.
SmtpClient class—Enables you to send email. You can use the SmtpClient class to send emails that contain attachments and HTML content.

These are only four examples of classes in the Framework. The .NET Framework contains almost 13,000 classes you can use when building applications.

You can view all the classes contained in the Framework by opening the Microsoft .NET Framework SDK documentation and expanding the Class Library node (see Figure 1.4). If you don’t have the SDK documentation installed on your computer, then see the last section of this chapter.


Each class in the Framework can include properties, methods, and events. The properties, methods, and events exposed by a class are the members of a class. For example, here is a partial list of the members of the SmtpClient class:

Properties
Host—The name or IP address of your email server
Port—The number of the port to use when sending an email message

Methods
Send—Enables you to send an email message synchronously
SendAsync—Enables you to send an email message asynchronously

Events
SendCompleted—Raised when an asynchronous send operation completes

If you know the members of a class, then you know everything that you can do with a class. For example, the SmtpClient class includes two properties named Host and Port, which enable you to specify the email server and port to use when sending an email message.

The SmtpClient class also includes two methods you can use to send an email: Send() and SendAsync(). The Send method blocks further program execution until the send operation is completed. The SendAsync() method, on the other hand, sends the email asynchronously. Unlike the Send() method, the SendAsync() method does not wait to check whether the send operation was successful.

Finally, the SmtpClient class includes an event named SendCompleted, which is raised when an asynchronous send operation completes. You can create an event handler for the SendCompleted event that displays a message when the email has been successfully sent.

Understanding Namespaces There are almost 13,000 classes in the .NET Framework. This is an overwhelming number. If Microsoft simply jumbled all the classes together, then you would never find anything. Fortunately, Microsoft divided the classes in the Framework into separate namespaces.

A namespace is simply a category. For example, all the classes related to working with the file system are located in the System.IO namespace. All the classes for working a Microsoft SQL Server database are located in the System.Data.SqlClient namespace.

Before you can use a class in a page, you must indicate the namespace associated with the class. There are multiple ways of doing this.

First, you can fully qualify a class name with its namespace. For example, because the File class is contained in the System.IO namespace, you can use the following statement to check whether a file exists:

System.IO.File.Exists(“SomeFile.txt”)

Specifying a namespace each and every time you use a class can quickly become tedious (it involves a lot of typing). A second option is to import a namespace. You can add an <%@ Import %> directive to a page to import a particular namespace. In

Finally, if you discover that you are using a namespace in multiple pages in your application, then you can configure all the pages in your application to recognize the namespace.

If you add the web configuration file in Listing 1.3 to your application, then you do not need to import the System.Net.Mail namespace in a page to use the classes from this namespace. For example, if you include the Web.config file in your project, you can remove the <%@ Import %> directive from the page in Listing 1.2.



You don’t have to import every namespace. The ASP.NET Framework gives you the most commonly used namespaces for free. These namespaces are as follows:

·        System 
·        System.Collections 
·        System.Collections.Specialized
·        System.Configuration
·        System.Text
·        System.Text.RegularExpressions
·        System.Web
·        System.Web.Caching
·        System.Web.SessionState
·        System.Web.Security
·        System.Web.Profile
·        System.Web.UI
·        System.Web.UI.WebControls
·        System.Web.UI.WebControls.WebParts
·        System.Web.UI.HTMLControls

The default namespaces are listed inside the pages element in the root web configuration file located at the following path:

\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\Web.Config

Understanding Assemblies An assembly is the actual .dll file on your hard drive where the classes in the .NET Framework are stored. For example, all the classes contained in the ASP.NET Framework are located in an assembly named System.Web.dll.

More accurately, an assembly is the primary unit of deployment, security, and version control in the .NET Framework. Because an assembly can span multiple files, an assembly is often referred to as a “logical” dll.

There are two types of assemblies: private and shared. A private assembly can be used by only a single application. A shared assembly, on the other hand, can be used by all applications located on the same server.

Shared assemblies are located in the Global Assembly Cache (GAC). For example, the System.Web.dll assembly and all the other assemblies included with the .NET Framework are located in the Global Assembly Cache.

Understanding the Common Language Runtime
The second part of the .NET Framework is the Common Language Runtime (CLR). The Common Language Runtime is responsible for executing your application code.

When you write an application for the .NET Framework with a language such as C# or Visual Basic .NET, your source code is never compiled directly into machine code. Instead, the C# or Visual Basic compiler converts your code into a special language named MSIL (Microsoft Intermediate Language).

MSIL looks very much like an object-oriented assembly language. However, unlike a typical assembly language, it is not CPU specific. MSIL is a low-level and platform-independent language.

When your application actually executes, the MSIL code is “just-in-time” compiled into machine code by the JITTER (the Just-In-Time compiler). Normally, your entire application is not compiled from MSIL into machine code. Instead, only the methods that are actually called during execution are compiled.

In reality, the .NET Framework understands only one language: MSIL. However, you can write applications using languages such as Visual Basic .NET and C# for the .NET Framework because the .NET Framework includes compilers for these languages that enable you to compile your code into MSIL.

The vast majority of developers building ASP.NET applications write the applications in either C# or Visual Basic .NET. Many of the other .NET languages in the preceding list are academic experiments.

Once upon a time, if you wanted to become a developer, you concentrated on becoming proficient at a particular language. For example, you became a C++ programmer, a COBOL programmer, or a Visual Basic Programmer.

When it comes to the .NET Framework, however, knowing a particular language is not particularly important. The choice of which language to use when building a .NET application is largely a preference choice. If you like case-sensitivity and curly braces, then you should use the C# programming language. If you want to be lazy about casing and you don’t like semicolons, then write your code with Visual Basic .NET.

All the real action in the .NET Framework happens in the Framework Class Library. If you want to become a good programmer using Microsoft technologies, you need to learn how to use the methods, properties, and events of the 13,000 classes included in the Framework. From the point of view of the .NET Framework, it doesn’t matter whether you are using these classes from a Visual Basic .NET or C# application.

Understanding ASP.NET Controls
ASP.NET controls are the heart of the ASP.NET Framework. An ASP.NET control is a .NET class that executes on the server and renders certain content to the browser.

For example, in the first ASP.NET page created at the beginning of this chapter, a Label control was used to display the current date and time. The ASP.NET framework includes over 70 controls, which enable you to do everything from displaying a list of database records to displaying a randomly rotating banner advertisement.

In this section, you are provided with an overview of the controls included in the ASP.NET Framework. You also learn how to handle events that are raised by controls and how to take advantage of View State.

Overview of ASP.NET Controls

The ASP.NET Framework contains over 70 controls. These controls can be divided into eight groups:
·       Standard Controls—The standard controls enable you to render standard form elements such as buttons, input fields, and labels. We examine these controls in detail in the following chapter, “Using the Standard Controls.”
·      Validation Controls—The validation controls enable you to validate form data before you submit the data to the server. For example, you can use a RequiredFieldValidator control to check whether a user entered a value for a required input field. These controls are discussed in Chapter 3, “Using the Validation Controls.”
·      Rich Controls—The rich controls enable you to render things such as calendars, file upload buttons, rotating banner advertisements, and multi-step wizards. These controls are discussed in Chapter 4, “Using the Rich Controls.”
·      Data Controls—The data controls enable you to work with data such as database data. For example, you can use these controls to submit new records to a database table or display a list of database records. These controls are discussed in detail in Part III of this book, “Performing Data Access.”
·     Navigation Controls—The navigation controls enable you to display standard navigation elements such as menus, tree views, and bread crumb trails. These controls are discussed in Chapter 19, “Using the Navigation Controls.”
·      Login Controls—The login controls enable you to display login, change password, and registration forms. These controls are discussed in Chapter 22, “Using the Login Controls.”
·      HTML Controls—The HTML controls enable you to convert any HTML tag into a server- side control. We discuss this group of controls in the next section of this chapter.

With the exception of the HTML controls, you declare and use all the ASP.NET controls in a page in exactly the same way. For example, if you want to display a text input field in a page, then you can declare a TextBox control like this:
<asp:TextBox id=”TextBox1” runat=”Server” /           

This control declaration looks like the declaration for an HTML tag. Remember, however, unlike an HTML tag, a control is a .NET class that executes on the server and not in the web browser.

When the TextBox control is rendered to the browser, it renders the following content:
<input name=”TextBox1” type=”text” id=”TextBox1” />         

The first part of the control declaration, the asp: prefix, indicates the namespace for the control. All the standard ASP.NET controls are contained in the System.Web.UI.WebControls namespace. The prefix asp: represents this namespace.

Next, the declaration contains the name of the control being declared. In this case, a TextBox control is being declared. This declaration also includes an ID attribute. You use the ID to refer to the control in the page within your code. Every control must have a unique ID.

The declaration also includes a runat=”Server” attribute. This attribute marks the tag as representing a server-side control. If you neglect to include this attribute, then the TextBox tag would be passed, without being executed, to the browser. The browser would simply ignore the tag.

Finally, notice that the tag ends with a forward slash. The forward slash is shorthand for creating a closing </asp:TextBox> tag. You can, if you prefer, declare the TextBox control like this:
<asp:TextBox id=”TextBox1” runat=”server”></asp:TextBox>

In this case, the opening tag does not contain a forward slash and an explicit closing tag is included.

Understanding HTML Controls
You declare HTML controls in a different way than you declare standard ASP.NET controls. The ASP.NET Framework enables you to take any HTML tag (real or imaginary) and add a runat=”server” attribute to the tag. The runat=”server” attribute converts the HTML tag into a server-side ASP.NET control.

For example, the page in Listing 1.5 contains a <span> tag, which has been converted into an ASP.NET control.


Notice that the <span> tag in Listing 1.5 looks just like a normal HTML <span> tag except for the addition of the runat=”server” attribute.

Because the <span> tag in Listing 1.5 is a server-side HTML control, you can program against it. In Listing 1.5, the current date and time are assigned to the <span> tag in the Page_Load() method.

The HTML controls are included in the ASP.NET Framework to make it easier to convert existing HTML pages to use the ASP.NET Framework. I rarely use the HTML controls in this book because, in general, the standard ASP.NET controls provide all the same functionality and more.

Understanding and Handling Control Events
The majority of the ASP.NET controls support one or more events. For example, the ASP.NET Button control supports the Click event. The Click event is raised on the server after you click the button rendered by the Button control in the browser.

The page in Listing 1.6 illustrates how you can write code that executes when a user clicks the button rendered by the Button control (in other words, it illustrates how you can create a Click event handler).



Notice that the Button control in Listing 1.6 includes an OnClick attribute. This attribute points to a subroutine named btnSubmit_Click(). The btnSubmit_Click() subroutine is the handler for the Button Click event. This subroutine executes whenever you click the button (see Figure 1.5).

You can add an event handler automatically to a control in multiple ways when using Visual Web Developer. In Source view, add a handler by selecting a control from the topleft drop-down list and selecting an event from the top-right drop-down list. The event handler code is added to the page automatically (see Figure 1.6).

In Design view, you can double-click a control to add a handler for the control’s default event. Double-clicking a control switches you to Source view and adds the event handler.


Finally, from Design view, after selecting a control on the designer surface you can add an event handler from the Properties window by clicking the Events button (the lightning bolt) and double-clicking next to the name of any of the events (see Figure 1.7).

It is important to understand that all ASP.NET control events happen on the server. For example, the Click event is not raised when you actually click a button. The Click event is not raised until the page containing the Button control is posted back to the server.

The ASP.NET Framework is a server-side web application framework. The .NET Framework code that you write executes on the server and not within the web browser. From the perspective of ASP.NET, nothing happens until the page is posted back to the server and can execute within the context of the .NET Framework.

Notice that two parameters are passed to the btnSubmit_Click() handler in Listing 1.6. All event handlers for ASP.NET controls have the same general signature.

The first parameter, the object parameter named sender, represents the control that raised the event. In other words, it represents the Button control which you clicked.

You can wire multiple controls in a page to the same event handler and use this first parameter to determine the particular control that raised the event. For example, the page in Listing 1.7 includes two Button controls. When you click either Button control, the textdisplayed by the Button control is updated (see Figure 1.8).



The second parameter passed to the Click event handler, the EventArgs parameter named e, represents any additional event information associated with the event. No additional event information is associated with clicking a button, so this second parameter does not represent anything useful in either Listing 1.6 or Listing 1.7.

When you click an ImageButton control instead of a Button control, on the other hand, additional event information is passed to the event handler. When you click an ImageButton control, the X and Y coordinates of where you clicked are passed to the handler.

The page in Listing 1.8 contains an ImageButton control that displays a picture. When you click the picture, the X and Y coordinates of the spot you clicked are displayed in a Label control (see Figure 1.9).


Understanding ASP.NET Pages
This section examines ASP.NET pages in more detail. You learn about dynamic compilation and code-behind files. We also discuss the events supported by the Page class.

Understanding Dynamic Compilation
Strangely enough, when you create an ASP.NET page, you are actually creating the source code for a .NET class. You are creating a new instance of the System.Web.UI.Page class.

The entire contents of an ASP.NET page, including all script and HTML content, are compiled into a .NET class.

When you request an ASP.NET page, the ASP.NET Framework checks for a .NET class that corresponds to the page. If a corresponding class does not exist, the Framework automatically compiles the page into a new class and stores the compiled class (the assembly) in the Temporary ASP.NET Files folder located at the following path:
\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files

The next time anyone requests the same page in the future, the page is not compiled again. The previously compiled class is executed and the results are returned to the browser. Even if you unplug your web server, move to Borneo for three years, and start up your web server again, the next time someone requests the same page, the page does not need to be re-compiled. The compiled class is preserved in the Temporary ASP.NET Files folder until the source code for your application is modified.

When the class is added to the Temporary ASP.NET Files folder, a file dependency is created between the class and the original ASP.NET page. If the ASP.NET page is modified in any way, the corresponding .NET class is automatically deleted. The next time someone requests the page, the Framework automatically compiles the modified page source into a new .NET class.

This process is called dynamic compilation. Dynamic compilation enables ASP.NET applications to support thousands of simultaneous users. Unlike an ASP Classic page, for example, an ASP.NET page does not need to be parsed and compiled each and every time it is requested. An ASP.NET page is compiled only when an application is modified.

Using Code-Behind Pages
The ASP.NET Framework (and Visual Web Developer) enables you to create two different types of ASP.NET pages. You can create both single-file and two-file ASP.NET pages. All the code samples in this book are written as single-file ASP.NET pages. In a single-file ASP.NET page, a single file contains both the page code and page controls. The page code is contained in a <script runat=”server”> tag.

As an alternative to a single-file ASP.NET page, you can create a two-file ASP.NET page. A two-file ASP.NET page is normally referred to as a code-behind page. In a code-behind page, the page code is contained in a separate file.

Installing the ASP.NET Framework
The easiest way to install the ASP.NET Framework is to install Visual Web Developer Express. You can download the latest version of Visual Web Developer from www.ASP.net, which is the official Microsoft ASP.NET website.

Installing Visual Web Developer Express also installs the following components:

. Microsoft .NET Framework version 3.5

. SQL Server Express

Visual Web Developer Express is compatible with the following operating systems:
. Windows 2000 Service Pack 4
. Windows XP Service Pack 2
. Windows Server 2003 Service Pack 1
. Windows x64 editions
. Windows Vista

I strongly recommend that you also download the .NET Framework SDK (Software Development Kit). The SDK includes additional documentation, sample code, and tools for building ASP.NET applications. You can download the SDK from the Microsoft MSDN website located at msdn.microsoft.com. The .NET Framework 3.5 SDK is included as part of the Microsoft Windows SDK for Windows Server 2008.

You can install Visual Web Developer Express on a computer that already has Visual Studio 2005 or Visual Web Developer 2005 installed. Different versions of the development environments can co-exist peacefully.

Furthermore, the same web server can serve ASP.NET 1.1 pages, ASP.NET 2.0 pages, ASP.NET 3.0 pages, and ASP.NET 3.5 pages. Each version of the .NET Framework is installed in the following folder:

C:\WINDOWS\Microsoft.NET\Framework

For example, on my computer, I have the following five versions of the .NET Framework installed (version 1.0, version 1.1, version 2.0, version 3.0, and version 3.5):

C:\WINDOWS\Microsoft.NET\Framework\v1.0.3705
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
C:\WINDOWS\Microsoft.NET\Framework\v3.0
C:\WINDOWS\Microsoft.NET\Framework\v3.5

The first three folders include a command-line tool named aspnet_regiis.exe. You can use this tool to associate a particular virtual directory on your machine with a particular version of the .NET Framework.

For example, executing the following command from a command prompt located in the v1.0.3705, v1.1.4322, or v2.0.50727 folders enables the 1.0, 1.1, or 2.0 version of ASP.NET for a virtual directory named MyApplication:
aspnet_regiis -s W3SVC/1/ROOT/MyApplication

By executing the aspnet_regiis.exe tool located in the different .NET Framework version folders, you can map a particular virtual directory to any version of the ASP.NET Framework.

The .NET Frameworks 3.0 and 3.5 work differently than earlier versions. The 3.0 and 3.5 versions build on top of the existing .NET Framework 2.0. To use these versions of the .NET Framework, you need to add the correct assembly references to your website and use the correct versions of the C# or VB.NET compilers. You reference these assemblies and configure the compiler within your application’s web.config file. When you create a new website in Visual Web Developer, the necessary configuration settings are included in your web.config file automatically.
You also have the option of targeting a particular version of the .NET Framework. To do this, select the menu option  Website, Start Options and select the Build tab. You can choose to target the .NET Framework 2.0, .NET Framework 3.0, or .NET Framework 3.5
















1 comment:

  1. Thanks for sharing this informative article on Overview of the ASP.NET Framework. If you want to ASP.Net Development Company for your project. Please visit us.

    ReplyDelete