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.
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
