Introduction to ASP.NET

This book in the Nutshell series covers the basics of the .NET development platform and new features in ASP.NET 1.1. The second edition includes bonus Visual Studio .NET add-in. This chapter is from the book, ASP.NET in a Nutshell, by G. Andrew Duthie and Matthew MacDonald, O'Reilly Media, 2004, ISBN: 0596005202.

Contributed by O'Reilly Media
Rating:

/ 39
August 24, 2004

Rate this Article:
MEH MEH++

SEARCH ASP FREE

The .NET Framework Class Library (FCL)

The FCL is a set of reusable object-oriented classes that provide basic platform functionality, from the data access classes of ADO.NET, to filesystem utility classes (including file, directory, and stream classes), to networking classes that allow easy implementation of DNS resolution, WHOIS lookups, and other network-related functionality. Developers can use the base classes directly or derive from these classes to provide customized functionality.

The FCL also contains all classes that make up ASP.NET. These include classes that implement all of the functionality of the ASP intrinsic objects, as well as classes that provide additional functionality, from a rich engine for caching output and data to the ASP.NET Server Control model. This functionality brings to ASP.NET the simplicity of control-based development that has long been available to Visual Basic developers.

In addition to classes that support Web application development, the FCL provides classes for developing console applications, Windows applications, and Windows NT or Windows 2000 Services.

The Common Type System (CTS)

The CTS describes the set of types that are supported by the CLR. This includes both value types, which include primitive data types such as Byte, Int16, Double, and Boolean, and reference types, which include arrays, classes, and the Object and String types.

Value types are types that store their values directly in memory and are accessed directly by name, as shown in the following code fragment:

'VB.NET
Dim myFloat As Single
myFloat = 3.1415
// C#
float myFloat;
myFloat = 3.1415;

In addition to these built-in data types, value types also include user-defined value types (types derived from the System.ValueType class) as well as enumerations.

Reference types are types that store a reference to the location of their values, rather than storing the value directly. Frequently, the value is stored as part of a defined class and is referenced through a class member on an instance of the class, as shown here:

'VB.NET
'Define class
Class myFloatClass
Public myFloat As Single
End Class

'Create class instance and assign value
Dim myInstance As New myFloatClass()
myInstance.myFloat = 3.1415

// C#
// Define class
class myFloatClass
{
float myFloat;
}

// Create class instance and assign value
myFloatClass myInstance = new myFloatClass();
myFloatClass.myFloat = 3.1415;

Individual language compilers may implement types using their own terminology. For example, while the .NET representation of a 32-bit integer is referred to as Int32, in Visual Basic .NET it is referred to as Integer and in C# as int. Internally, however, both Visual Basic’s Integer and C#’s int are implemented as the .NET Int32 type.

Boxing and unboxing

Converting to and from value and reference types is accomplished through a process called boxing and unboxing. Boxing refers to the implicit conversion of a value type, such as a C# int, to a reference type (usually Object). For this conversion to take place, an instance of type Object is created and the value type’s value and type is copied into it—in this case, int. Unboxing refers to the explicit conversion of an Object type into a specific value type. The code example shown here demonstrates boxing and unboxing:

// C#
int myInt = 123; // declare an int and set its value to 123
object myObj = myInt; // value of myInt is boxed into myObject
int myOtherInt = (int)myObject; // unbox myObject into myOtherInt

The Common Language Infrastructure (CLI)

The CLI is a subset of the .NET Framework that has been submitted for standardization through the ECMA standards body. The CLI includes the functionality of the Common Language Runtime, as well as specifications for the Common Type System, type safety rules, Metadata, and Intermediate Language. It also includes a subset of the Framework Class Library that includes a Base Class Library (for built-in types and basic runtime functionality), a Network Library (for simple networking services and access to network ports), a Reflection Library (for examining types and retrieving information about types at runtime), an XML Library (for parsing XML), and Floating Point and Extended Array Libraries.

Microsoft has also committed to providing what they refer to as a “sharedsource” implementation of the CLI, which will be available for both the FreeBSD and Windows operating systems. You can find out more about the shared-source CLI implementation at http://msdn.microsoft.com/library/en-us/dndotnet/html/mssharsourcecli2.asp.

There is also a group working on an open source implementation of the CLI, based on the ECMA specifications, called Mono. You can find out more about Mono at http://www.go-mono.org/.

Information on the ECMA standardization process, including documentation of the proposed standards, is available at http://msdn.microsoft.com/net/ecma/.

The Common Language Speciﬁcation (CLS)

The CLS is a subset of the types supported by the CLR, as well as a set of rules that language and compiler designers must follow. The purpose of the CLS is to provide robust interoperability between .NET languages, including the ability to inherit classes written in one .NET language in any other .NET language and cross-language debugging.

The rules defined by the CLS apply only to publicly exposed features of a class. For example, the internal implementation of a class can use non-CLS–compliant types (such as the unsigned integer types), but as long as only CLS-compliant members are exposed publicly, the class can still take full advantage of the interoperability features enabled by the CLS.

Classes

While not a term specific to the .NET platform, the term class may be new to many ASP developers. A class is essentially the blueprint for an object. It contains the definition for how a particular object will be instantiated at runtime, such as the properties and methods that will be exposed publicly by the object and any internal storage structures.

Developers work with classes by creating instances of the class at runtime using the new keyword, as shown here:

// Instantiate the .NET StreamReader class in C# System.IO.StreamReader sr;
sr = new System.IO.StreamReader("C:\\Test.txt");
string Line;

while(sr.Peek() != -1)

{
Line = sr.ReadLine();
Response.Write(Server.HtmlEncode(Line) + " <br/>");
}

We preface the name of the class, StreamReader, with its namespace name, System.IO, to prevent naming collisions with other classes in different assemblies that might have the same name and to ensure that we get the StreamReader class we expect. We’ll discuss namespaces and assemblies later in this section.

In C#, the lowercase new keyword is used to instantiate classes. In Visual Basic .NET, the New keyword is uppercase, but since the Visual Basic language is not case-sensitive, this is a standard practice, rather than a requirement enforced by the compiler. C#, on the other hand, is case-sensitive, so keep this in mind when switching between C# and VB.NET.

Namespaces

Namespaces, a key part of the .NET Framework, provide scope to both preinstalled framework classes and custom-developed classes. Namespaces are declared for a given set of classes (types) by enclosing those classes in one of the following declarations:

// C#
namespace myNamespace
{
class myClass
{
// class implementation code
}
}

' VB.NET
Namespace myNamespace
Class myCls
' class implementation code
End Class
End Namespace

Namespaces may also be nested, as shown here:

' VB.NET
Namespace myFirstNamespace
Public Class myCls
    ' class implementation code
End Class
Namespace mySecondNamespace
    Public Class myCls
     ' class implementation code
End Class
Public Class myCls2
    ' class implementation code
End Class
End Namespace
End Namespace

This code is perfectly valid because we’ve declared the second myCls in the nested namespace mySecondNamespace. If we tried to declare two identically named classes within the same namespace, we would get a compiler error informing us that there was a naming conflict, because each class name must be unique within its namespace. To use the classes we just declared, we can do something like the following:

' VB.NET
Imports System
Imports myFirstNamespace
Imports myFirstNamespace.mySecondNamespace

Module namespaces_client_vb

Sub Main()
Dim newClass As New myFirstNamespace.myCls
Dim newClass2 As New myCls2 Console.WriteLine("Object creation succeeded!")
End Sub

End Module

We use the Imports keyword in Visual Basic .NET to enable the use of member names from these namespaces without explicitly using the namespace name. However, because we used the class name myCls in both the myFirstNamespace and mySecondNamespace namespaces, we need to use the fully qualified name for this class, while we are able to instantiate myCls2 with only the class name. We can just as easily use these classes from C#, as shown here:

using System;
using myFirstNamespace;
using myFirstNamespace.mySecondNamespace;

class namespaces_client

{
public static void Main()
{
myFirstNamespace.myCls newClass = new myFirstNamespace.myCls();
myCls2 newClass2 = new myCls2();
Console.WriteLine("Object creation succeeded!");
}
}

C# uses the using keyword for importing namespaces. Notice that in both cases, in addition to importing the namespaces we defined, we’ve also imported the System namespace. This is what allows us to use the Console class defined in the System namespace to write to a console window without referring explicitly to System.Console.

Classes that are part of the .NET Framework are organized by functionality into namespaces that make them easier to locate and use. All classes that are a part of the .NET Framework begin with either “System” or “Microsoft.” Examples include:

System -- Contains all the .NET primitive data types as well as utility classes such as Console and Math that are apt to be widely used in .NET applications.
System.Collections -- Contains classes used to implement various kinds of collections in .NET, including ArrayList, Dictionary, and Hashtable.
System.Data -- Contains classes used to access and manipulate data, as well as child namespaces such as System.Data.SqlClient, which contain data access classes specific to a particular data provider.
System.Web -- Contains classes used to process web requests, as well as child namespaces such as System.Web.UI, which contains such classes as the Page class, the basis for all ASP.NET pages.

Assemblies

Also known as Managed DLLs, assemblies are the fundamental unit of deployment for the .NET platform. The .NET Framework itself is made up of a number of assemblies, including mscorlib.dll, among others. The assembly boundary is also where versioning and security are applied.

An assembly contains Intermediate Language generated by a specific language compiler, an assembly manifest (containing information about the assembly), type metadata, and resources. We’ll discuss IL, manifests, and metadata later in this section.

Assemblies can be either private, residing in the directory of the client application from which they are used (or, in the case of ASP.NET, in the / bin subdirectory of the Web application), or shared. Shared assemblies are stored in a common location called the Global Assembly Cache (GAC). Assemblies that are to be installed in the GAC must be strongly named, which means that they must have a cryptographic key associated with them. Strong naming can be accomplished either through Visual Studio .NET, or you can use the sn.exe tool supplied with the .NET Framework SDK to generate a key pair for signing the assembly, and then use the al.exe tool to create the signed assembly based on the generated key. We’ll demonstrate creating and sharing strongly named assemblies in Chapter 6.

Assemblies are self-describing, thanks to the manifest contained within them. One advantage of their self-describing nature is that it makes it possible for different versions of the same assembly to be run side by side. Clients can then specify the version of the assembly that they require, and the CLR will make sure that the correct version of the assembly is loaded for that client at runtime.

Intermediate Language (IL)

IL, also known as MSIL (for Microsoft Intermediate Language), is a processor-independent representation of executable code. IL is similar in some ways to assembly code, but it is not specific to a particular CPU; rather, it is specific to the CLR. IL is generated by each of the language compilers that target the CLR. As mentioned above, .NET assemblies contain IL that is to be executed by the CLR.

At runtime, the CLR just-in-time (JIT) compiles the IL to native code, which is then executed. There is also a tool called ngen.exe, which is supplied with the .NET Framework SDK and allows you to precompile assemblies to native code at install time and cache the precompiled code to disk. However, while precompiling an assembly to native code will improve the startup time of an assembly, the JIT process used by the CLR performs optimizations that may allow JITed code to perform better than precompiled code, the difference in performance will depend on the code being executed, and how subject to these optimizations it is.

Managed Execution

Managed execution refers to code whose execution is managed by the CLR. This execution includes memory management, access security, cross-language integration for debugging and/or exception handling, and many other features. Managed assemblies are required to supply metadata that describes the types and members of the code contained within the assembly. This information allows the CLR to manage the execution of the code.

Note that not all languages in Visual Studio .NET are managed. While Visual C++ offers what are called the “Managed Extensions for Visual C++,” it is still possible to write unmanaged code in Visual C++.

Manifests, Metadata, and Attributes

Metadata and manifests are key pieces of the managed execution world. Manifests are the portion of an assembly that contains descriptive information about the types contained in the assembly, the members exposed by the assembly, and the resources required by the assembly. The manifest contains metadata, which, simply put, is data that describes the assembly. Some metadata is generated by the language compiler at compile time. The developer may add other metadata at design time through the use of attributes. Attributes are declarations added to code that describe some aspect of the code or modify the code’s behavior at runtime.

Attributes are stored with an assembly as metadata and are used for many purposes in the .NET Framework—from the attribute used to turn a normal method into a web service to attributes used to define how custom controls interact with the Visual Studio .NET environment.

Object Orientation in the .NET Platform

The .NET Framework was built to be object oriented from the ground up. What does this mean? For those of you who are unfamiliar with object-oriented programming, here’s a quick review.

We’ve already discussed classes. Classes are the blueprints or templates from which objects are created. Objects, the heart of object-oriented programming, are usable instances of a class. Objects expose properties, which contain data related to or about the object, and/or methods, which allow actions to be performed on the object.

In object-oriented programming, objects need to support three important qualities: encapsulation, inheritance, and polymorphism.

Encapsulation refers to the ability of an object to hide its internal data from outside view and allow access to only that data through publicly available methods. This helps prevent clients from accidentally or purposefully leaving object data in a corrupt state and makes it easier for the developer of the class on which the object is based to change the internal implementation of these data members without breaking its clients.

Inheritance refers to the ability to derive one class from another. This allows developers to create a new class based on an existing class. The new class inherits all methods and properties of the existing class. The developer can then add new methods or properties or override existing methods. Inheritance allows you to develop specialized versions of objects that are customized to meet your precise needs. We’ll discuss this type of scenario more in Chapter 6.

The .NET Framework offers only single inheritance—that is, a class may only derive from a single base class. This is different from languages such as C++, which allow classes to be derived from multiple base classes.

Polymorphism refers to the ability of multiple classes derived from the same base class to expose methods with the same name—all of which clients can call in exactly the same way, regardless of the underlying implementation. Thus, a Car class could expose a Start method and a derived class SportsCar could override that Start method to provide a different implementation. From the client’s perspective, however, both methods are used the same way.

This is a very high-level overview of object-oriented programming. While we’ll discuss object-oriented techniques in more depth throughout the book, if you are unfamiliar with the topic you may want to pick up a book that specifically addresses object-oriented programming.

Why Is It Important? Rapid Development and Reuse!

What’s important about the object-oriented nature of the .NET platform is that it allows much faster development than did previous generations of Windows development technologies and offers much greater opportunities for reuse.

Because the functionality of the .NET Framework is exposed as a set of object-oriented classes rather than a set of obscure and finicky API calls, many operations that were difficult or downright impossible in classic ASP are simple in ASP.NET. For example, about ten lines of code can perform a DNS lookup on a domain name using the classes in the System.Net and System.Net.Sockets namespaces. This task wasn’t even possible in classic ASP, without the use of external components.

What’s more, because many classes in the .NET framework can be used as base classes, it is easy to reuse them in your own applications by deriving from a class to provide common functionality and then extending the derived class to add functionality specific to your application. In fact, much of the .NET Framework is built this way. For example, all classes that make up the ASP.NET Server Controls are ultimately derived from the Control class of the System.Web.UI namespace, which provides properties and methods common to all server controls.

OO Is at the Heart of Every ASP.NET Page

One of the coolest things about object orientation in ASP.NET is that you don’t have to know much about how to use it since most of it is under the covers for basic page development. Every ASP.NET page implicitly inherits from the Page class of the System.Web.UI namespace, which provides access to all ASP.NET implementations of the intrinsic objects that were introduced in classic ASP, such as Request, Response, Session, and Application, and to a number of new properties and methods. One advantage of this is that each page is compiled into an assembly based on the Page class, providing substantial performance improvements over classic ASP, in which code was interpreted at runtime.

Object orientation is also the key to another important new feature of ASP.NET: code-behind. Code-behind allows developers to separate executable code from the HTML markup that makes up the user interface. Executable code is placed in a module called a code-behind file, which is associated with the ASP.NET page via an attribute in the page. The code-behind file contains a class that inherits from the Page class. The ASP.NET page then inherits from the code-behind class, and at runtime, the two are compiled into a single executable assembly. This compilation allows a combination of easy separation of UI and executable code at design time with high performance at runtime.

Choosing a Language

Choosing which language to use when developing ASP.NET applications is both easier and harder than choosing a language for classic ASP development. It is harder because it may be intimidating for some to choose between a substantially revised Visual Basic and a completely new language, C#. It is easier because the choice of language no longer requires giving up substantial amounts of functionality for your preferred language.

As in many other cases, including language choice in classic ASP, a lot of the decision is determined by where you’re coming from. If you’re:

An experienced ASP developer who has used VBScript -- You’ll probably prefer Visual Basic.NET.
An experienced ASP developer who’s used JScript -- You’ll want to look at C# or JScript.NET (keeping in mind that finding code examples in C# is easier, since the novelty of the language makes it more interesting for many).
An experienced Visual Basic developer -- Visual Basic.NET is the obvious choice, but you may also find it worthwhile to check out C#, which offers a lot of the power of C++ without such a steep learning curve.
An experienced C, C++, or Java developer -- You’ll probably feel right at home with C#, which, as a C-derived language, shares a lot of syntax with these languages.
New to ASP.NET development, with no prior ASP experience -- Visual Basic.NET will probably be easiest to learn, although C# runs a close second.

Because of the level of cross-language interoperability in .NET, your choice needn’t be an either/or. You can feel free to create applications and classes in Visual Basic.NET, C#, JScript.NET, or any .NET-enabled language, knowing that they will be able to work together smoothly and easily, thanks to the CLR.

Why and When Would I Use ASP.NET?

You should use ASP.NET for any new projects you are about to start for the following reasons:

Reduced development time
Increased performance
Increased application stability
Increased scalability
New ASP.NET features (see the discussion later in this chapter)

Some of these benefits, such as reduction in development time, assume familiarity with the .NET development platform. If you are starting your first ASP.NET development project, you should allow some time for getting up to speed on the new platform. Subsequent projects should see reduced development time over classic ASP, as developers become more familiar with the platform.

In addition to these factors, ASP.NET, like ASP, is available for free. The only costs associated with ASP.NET development are the costs of the operating system on which you wish to run your application (Windows 2000, Windows XP, or Windows Server 2003) and the cost of the development environment you choose to use. Of course, as with classic ASP, you can use free or inexpensive text editors to create your applications. Given that the .NET Framework is a free add-on to Windows (and is integrated with the Windows Server 2003 line), it is possible to create ASP.NET applications without spending a penny beyond the cost of the operating system and hardware on which it will run. Integrated development environments, such as Microsoft Visual Studio .NET 2003, are also available at an additional cost and greatly simplify ASP .NET development.

Porting an Existing Application to ASP.NET

Why and When Would I Port an Existing Application to ASP.NET?

A trickier question is, “When will it be worthwhile to make the effort to migrate an existing application from ASP to ASP.NET?” The reality is that while classic ASP and ASP.NET have many common features, for most applications, it will not be a trivial task to migrate an application from one to the other. Changes in languages, as well as some changes in the way that ASP.NET operates compared to classic ASP, mean that depending on how your classic ASP application is structured, migration could require a significant amount of effort.

How do you decide whether a migration is worthwhile? If your application is in production, meets your needs functionally and in terms of performance and scalability, and you do not anticipate further development on the application, it’s probably best to simply run it as a classic ASP application. One big plus of the ASP.NET architecture is that it runs side by side with classic ASP, so you don’t have to migrate applications. Keep in mind, however, that while classic ASP and ASP.NET applications can run side by side, even in the same directory, they do not share Session and Application context. Thus, you will need to devise your own means of transferring any information you store in the Session or Application collections to and from ASP and ASP.NET, if you want to share that information between classic ASP and ASP.NET pages.

If your application is due for a new development cycle or revision, it’s worth examining the types of functionality that your application uses and examining whether ASP.NET would be helpful in meeting the needs of the application. For example, if you have an application that struggles to meet your needs in terms of performance and scalability, the improved performance of the compiled-code model of ASP.NET and its new out-of-process Session State support may enable you to meet these goals easily.

What’s important to consider is balancing the cost of migration against the benefits offered by migration. In this book, we will discuss the improvements and benefits offered by ASP.NET. It is left as an exercise for the reader to weigh these improvements against one another and determine whether to migrate a particular application.

New Features in ASP.NET

We’ll close our introductory look at the .NET platform with a list of new features that are unique to ASP.NET and the chapter in which each will be discussed.

Web Forms

A new feature that, in combination with an editor such as Visual Studio .NET, provides the ASP.NET developer the same drag and drop development convenience enjoyed by Visual Basic developers for years. Web Forms improve the speed of development by encapsulating frequently used features into server controls, which are declared using a tag-based syntax similar to HTML and XML. We’ll discuss Web Forms in Chapters 3 and 12.

Web services

Web services allow developers to expose the functionality of their applications via HTTP and XML so that any client who understands these protocols can call them. Web services can make the task of application integration easier, particularly in situations in which application-to-application integration is made difficult by firewalls and/or differing platforms. We’ll discuss web services in Chapter 4.

Server controls

Server controls are declared using an HTML-like syntax, making them easier to work with for page UI designers. They are executed on the server, returning HTML to the browser. Server controls may be manipulated on the server programmatically and provide power and flexibility for applications that must support a variety of browsers. We’ll discuss using server controls in Chapter 5 and custom server control development in Chapter 6.

Validation

One group of server controls is designed to simplify the task of validating user input. It includes controls to validate required fields, to compare one field to another or to a specific value for validation, and to validate user input using regular expressions, which allow you to specify a format that user input must follow to be valid. Validation controls will be discussed in Chapter 5.

Improved security

ASP.NET offers tighter integration with Windows-based authentication, as well as two new authentication modes: forms-based authentication (which allows users to enter authentication credentials in a standard HTML form, with the credentials validated against your choice of backend credential store) and Passport authentication (which makes use of Microsoft’s Passport authentication service). We’ll discuss these improvements and new techniques in Chapter 9.

New Features in ASP.NET v1.1

In Version 1.1 of the .NET Framework, several features have been added that are of interest to ASP.NET developers. These include:

Request Validation

Request Validation, when enabled (the default), checks all forms of posted input (form fields, querystring, etc.) and raises an exception if any HTML or script code is found. This can help prevent cross-site scripting attacks in your applications. We’ll discuss Request Validation further in Chapter 9.

Side by side execution

Starting with ASP.NET 1.1, you can choose which version of the .NET Framework your application will run against. Assuming you have both Version 1.0 and Version 1.1 installed, you can configure individual applications to run against either version. We’ll discuss how to do this in Chapter 8.

Built-in mobile control support

In Version 1.0, support for targeting mobile devices such as cell phones and PDAs was provided via a set of controls available as a separate download. In Version 1.1, these controls have been fully integrated into the .NET Framework, and a new application type has been added to Visual Studio .NET 2003 to support development of ASP.NET applications for mobile devices. We’ll discuss mobile development in Chapter 5.

ADO.NET enhancements

In Version 1.0, developers wishing to access data from Oracle and/or ODBC data sources had to download and install a separate data provider for these data sources. In Version 1.1, the ODBC and Oracle data providers have been integrated into the .NET Framework.