The Web Forms Model

2017-11-03 09:05:06

Overview

A journey of a thousand miles begins with a single step.

-Lao Tzu

ASP.NET is a Web development platform that provides the programming model and software infrastructure necessary to build enterprise-class applications. Although largely syntax compatible with its popular predecessor—Active Server Pages (ASP)—ASP.NET is a revolutionary new programming framework designed to enable the rapid development of Web applications and Web services. As part of the Microsoft .NET platform, ASP.NET provides a component-based, extensible, and easy-to-use way to build, deploy, and run Web applications that target any browser or mobile device.

ASP.NET is supported on a variety of platforms, including Microsoft Windows 2000 with at least Service Pack 2, Windows XP Professional, and Windows Server 2003. To develop ASP.NET server applications, Internet Information Services (IIS) version 5.0 or later is also required. Other software you need—for example, Microsoft Data Access Components (MDAC) 2.7—is automatically installed when you set up the .NET Framework.

ASP.NET fits perfectly in the trend that has shifted the focus of development from client/server applications to Web-based architectures and Internet-deployed applications. It is the next step in the evolution and a giant step indeed. ASP.NET is the summation of Web development technologies that rapidly followed one after another in the past five years—one building over another, and each filling the gaps of its predecessor. As a result, ASP.NET is currently the most technologically advanced, feature-rich, and powerful platform for building distributed applications transported by the HTTP protocol. The Web Forms model is simply a blanket term that figuratively describes the abstraction model ASP.NET constructs atop the evergreen, old, and faithful HTTP protocol.

What s ASP NET, Anyway?

Prior to the advent of ASP.NET, three main technologies and platforms were available to develop Web applications: ASP, Java Server Pages (JSP), and the open source Web platform commonly referred to as LAMP (Linux plus Apache plus MySQL plus either Perl, Python, or PHP as the programming language).

Note

For completeness, we should also mention a couple of platform-specific, lower-level technologies that ASP and JSP rely on. ASP is actually an Internet Server Application Programming Interface (ISAPI) extension, whereas JSP is implemented as a special servlet application. ISAPI extensions on IIS-based platforms and servlets on Java-based systems let you create server-side, Web-deployed applications using a more classic approach. You write a module that builds and renders the page rather than declaratively design the page using a mix of markup text and embedded code.

Although each has language-specific and architecture-specific features, all these Web development platforms are designed to create interactive pages as part of a Web-based application. To some extent, all enable developers to separate programming logic from the page layout through the use of components that the page itself is responsible to call and render. Aside from this common ultimate goal, significant differences exist among those platforms, most of which relate to the programming model and languages they promote and support. For example, JSP exploits the Java framework of classes and, with JavaBeans, provides an effective extensibility model for reusing components. In addition, JSP supports tag customization and lets developers associate code with a custom tag definition. Finally, because it's a key element of the Java 2 Enterprise Edition (J2EE) platform, JSP relies on the Java language, a first-class language as opposed to the scripting languages used by both ASP and LAMP platforms. So how does ASP.NET fit in exactly?

Like ASP and other Web development environments, ASP.NET also works on top of the HTTP protocol and takes advantage of HTTP commands and policies to set up two-way, browser-to-server communication and cooperation. What really differentiates ASP.NET from the plethora of other Web development technologies—and what makes it especially revolutionary—is the abstract programming model it propounds, the Web Forms model. In addition, the whole ASP.NET platform comes as a native part of the Microsoft .NET Framework. To be sure you grasp the importance of this last point, let me explain. ASP.NET applications are now compiled pieces of code, are made of reusable and extensible components, can be authored with first-class languages (including C#, Microsoft Visual Basic .NET, JScript .NET, and J#), and can access the entire hierarchy of classes in the .NET Framework.

In short, ASP.NET combines the best of all worlds. It is syntax compatible (and to a large extent, also language compatible) with ASP. It provides the same object-oriented features as JSP applications (tag customization, first-class compiled languages, components, extensibility, and reusability). And as icing on the cake, ASP.NET delivers a wealth of goodies, tools, and powerful system features that can be effectively grouped within the blanket expression tools for abstracting the HTTP programming model. Lots of programmer-friendly classes let you develop pages using typical desktop methods. The Web Forms model promotes an overall event-driven approach, but it's deployed over the Web and has the potential to target any vendor's platform through the support of XML.

Note

From a technical point of view, ASP.NET adopts the best of the ASP and JSP programming models. Conversely, it doesn't inherit much from the LAMP platform in terms of technical aspects. The appeal of LAMP is that it excels as a robust and extensible (because it is open-source) platform with flourishing and proactive grassroots community sites and Web boards.

Whichever way you look at ASP.NET, it's a quantum leap beyond any other Web programming style you might have experienced in the past. In this chapter, we'll present an overview of the ASP.NET platform, introducing topics such as the Web Forms model, structure of Web pages, and tasks involved when building ASP.NET applications. In Chapter 2, "Web Forms Internals," we'll drill down into the architectural elements of the Web Forms model, and then bear off into the sea of ASP.NET features and widgets. So get ready, and let the show begin.

Programming in the Age of Web Forms

A key point I need to explain so that you understand the rationale behind the ASP.NET Web Forms model is that there is a need to provide a better strategy to deal with the strong and growing demand for cheap Web interaction. As a matter of fact, the HTTP protocol, especially its stateless nature, creates a sort of bottleneck for the development of Web applications. On the other hand, the inherent simplicity of HTTP is the key to its worldwide adoption and effectiveness—in short, we probably couldn't have the Internet as we know it without a protocol like HTTP. Yet, as demand increases, programmers have to devise better ways of setting up easy and effective communication from the client to the server and vice versa.

Various techniques have been experimented with over time to smooth the communication across different pages and across multiple invocations of the same page. Programmers are used to thinking in terms of a client-generated action that results in a server-side reaction. Such a basic and fundamental pattern simply cannot be accomplished, at least not literally, over the Web. A certain degree of abstraction and some system-provided services are needed to make smooth communication happen. Although they aren't perfect, JSP and ASP let programmers target any browser while coding against a relatively familiar and understandable model. ASP, much more than JSP, thinks declaratively and has quite a slim and scanty object model. Overall, programmers who become Web programmers are forced to adopt a different mindset and toss the familiar action/reaction paradigm out the door.

Event Driven Programming over HTTP

With Web Forms, the event-driven model of interaction finally comes to the Web. Implementing an event model over the Web requires any data related to the client-side user's activity to be forwarded to the server for corresponding and stateful processing. For the model to work, the server needs to process the output of client actions and trigger reactions while being aware of the overall state of the application. The state of the application contains two types of information: the state of the client and the state of the session. The state of the client is easily accessible through the syntax and the implementation of the

HTML element. But what about the overall state of the session?

As mentioned, HTTP is a stateless protocol, which means two successive requests across the same session are resolved by newly instantiated environments in which no session-specific information is maintained, except all the information the application itself might have stored in global objects. In ASP, reentrant forms are a common way to work around such a system limitation. A reentrant form is an HTML element that posts to the same page that contains it. Reentrant forms alone do not fully solve the issue. However, by combining them with code blocks and hidden fields storing state information that is critical for the page, many developers elegantly overcame the obstacle.

What was once an ASP best-practice has been standardized and integrated in the ASP.NET runtime to become the key feature that endows ASP.NET applications with automatic state maintenance. The ASP.NET runtime carries the page state back and forth across page requests. When generating HTML code for a given page, ASP.NET encodes and stuffs the state of server-side objects into a few hidden, and transparently created, fields. When the page is requested, the same ASP.NET runtime engine checks for embedded state information—the hidden fields—and utilizes any decoded information to set up newly created instances of server-side objects. The net effect of such a mechanism is not unlike the Windows Forms model on the desktop and is summarized in Figure 1-1.

Figure 1-1: Comparing the Windows Forms and Web Forms models in the .NET Framework.

The Windows Forms model stems from the typical event-driven desktop programming style. No matter what connectivity exists between the client and server components, the server always works in reaction to the client's input. The server is aware of the overall application state and operates in a two-tier, connected manner. The Web Forms model needs some machinery to support the same event-driven programming model. In Figure 1-1, the needed machinery is represented by the state deserialization that occurs when the page is requested and the state serialization performed when the HTML response is being generated.

In charge of this filtering work is the ASP.NET HTTP runtime—a piece of code that extends and specializes the overall capabilities of the hosting Web server. Reentrant forms and hidden fields are the low-level tools used to perform the trick. Such a model wouldn't be as effective without a back-end, rich object model spanning the whole content of the server page. Crucial to the building and effective working of the ASP.NET development platform is the component model. The ASP.NET component model is shared with all other types of .NET applications—Windows Forms, console applications, and Web services.

The ASP.NET object model is a branch of the .NET Framework and is designed to provide a server-side counterpart to virtually any HTML page elements, such as HTML tags like and and page-wide tags like

and

Pro ASP.NET (Ch 01)

String Converter

Blank lines in the preceding listing separate the three sections—directives, code, and page layout. Notice the unsparing use of the runat attribute—it's one of the most important pieces of the whole ASP.NET jigsaw puzzle. Later in this chapter, we'll discuss runat in more detail. For now, it suffices to say that the runat attribute promotes an otherwise lifeless server-side tag to the rank of a component instance. Let's quickly review the code.

Thanks to the runat attribute, the input text box becomes an instance of the HtmlInputControl class when the page is processed on the server. The Value property of the class returns the current content of the control. This value is converted to uppercase and then assigned to the InnerText property of the server-side control used to render an HTML tag. When the user clicks the Submit button, the page automatically posts back to itself. This time, the magic is performed by the runat attribute set for the

tag. Once on the server, the current value of the text box is read and automatically assigned to a newly created instance of the HtmlInputControl. Next, the code associated with the OnServerClick event runs. The code works on controls whose state has been restored and updated with client information. When the MakeUpper event handler completes, the page is ready for rendering. At this point, updated HTML code is sent to the browser.

To test the page, copy the .aspx file to your Web server's root directory. Normally, this is c:inetpubwwwroot. If you want, create an ad hoc virtual directory. Next, point the browser to the page. Figure 1-2 shows what you get.

Figure 1-2: Our first ASP.NET page in action.

No matter how simple you keep a test ASP.NET page, a lot of complex features and techniques are always involved. This page is no exception. In the following chapters, you'll learn more about server-side controls and the difference between HTML and Web controls. You'll also see how to deploy real applications and not just individual pages. Now that we've dirtied our hands with some ASP.NET code, let's step back and review the layers that actually make an ASP.NET page.

The Processing Directives of a Page

Directives configure the run-time environment that will execute the page. In ASP, only one directive was supported—@Language—and you had to place it on the very first line of the page. The following code shows an ASP directive:

<% @Language="VBScript" CodePage="1232" %>

Several new directives have been added to ASP.NET and, at the same time, their usage has been made easier and dependent on less strict conditions. In ASP.NET, directives can be located anywhere in the page, although it's a good and common practice to place them at the beginning of the file. In addition, the name of a directive is case-insensitive and the values of directive attributes don't need to be quoted.

Tip

The ASP @Language directive is no longer officially supported in ASP.NET. The same goal is accomplished by the Language attribute within the @Page directive. However, for migration purposes, ASP.NET treats the old-style @Language directive block as an @Page directive with the Language attribute set. As a result, the ASP-style syntax shown below is still accepted:

<% @Language="VBScript" CodePage="1232" %>

It gets silently translated into the following code:

<% @Page Language="VBScript" CodePage="1232" %>

The ASP.NET @Page directive supports the same set of processing directives as ASP—CodePage, EnableSessionState, LCID, Transaction—plus a few more.

The most important and most frequently used directive in ASP.NET is @Page. The complete list of ASP.NET directives is shown in Table 1-1.

*Table 1-1: Directives Supported by ASP.NET Pages*
Directive	Description
@ Assembly	Links an assembly to the current page or user control
@ Control	Defines control-specific attributes that guide the behavior of the control compiler
@ Implements	Indicates that the page, or the user control, implements a specified .NET Framework interface
@ Import	Indicates a namespace to import into a page or user control
@ OutputCache	Controls the output caching policies of a page or user control
@ Page	Defines page-specific attributes that guide the behavior of the page compiler and the language parser that will preprocess the page
@ Reference	Links a page or user control to the current page or user control
@ Register	Creates a custom tag in the page or the control. The new tag (prefix and name) is associated with the namespace and the code of a user-defined control

With the exception of @Page and @Control, all directives can be used both within a page and a control declaration. @Page and @Control are mutually exclusive. @Page can be used only in .aspx files, while the @Control directive can be used only in .ascx files.

Note

As we'll see in more detail in Chapter 10 and Chapter 18, ASP.NET features two types of user-defined controls. Custom controls are controls that derive from existing .NET Framework classes. User controls (also known as pagelets) are smaller and simpler ASP.NET pages that can be embedded in host pages and programmatically driven through methods and properties. Custom controls are created as assemblies and have a .dll extension. User controls are source files, similar to ASP.NET pages, but they have the .ascx extension.

We'll cover the @Control, @OutputCache, and @Register directives in detail in Chapter 10. In the meantime, let's learn more about the other, more page-specific, directives.

The syntax of a processing directive is unique and common to all supported types of directives. Multiple attributes must be separated with blanks, and no blank can be placed around the equals sign (=) that assigns a value to an attribute, as the following line of code demonstrates:

<%@ Directive_Name attribute="value" [attribute="value"...] %>

Each directive has its own closed set of typed attributes. Assigning a value of the wrong type to an attribute, or using a wrong attribute with a directive, results in a compilation error.

Important

The content of directive attributes is always rendered as plain text. However, attributes are expected to contain values that can be rendered to a particular type. When the ASP.NET page is parsed, all the directive attributes are extracted and stored in a dictionary. The names and number of attributes must match the expected schema for the directive. The string that express the value of an attribute is valid as long as it can be converted into the expected type. For example, if the attribute is designed to take a Boolean value, "true" or "false" are its only acceptable values.

The @Page Directive

The @Page directive can be used only in .aspx pages and generates a compile error if used with other types of ASP.NET pages such as controls and Web services. Each .aspx file is allowed to include at most one @Page directive. Although not strictly necessary from the syntax point of view, the directive is realistically required by all pages of some complexity.

@Page features about 30 attributes that can be logically grouped in three categories: compilation (Table 1-2), overall page behavior (Table 1-3), and page output (Table 1-4). Each ASP.NET page is compiled upon first request, and the HTML actually served to the browser is generated by the methods of the dynamically generated class. Attributes in Table 1-2 let you fine-tune parameters for the compiler and choose the language to use.

Table 1-2: @Page Attributes for Page Compilation

Attribute

Description

ClassName

Specifies the name of the class that will be dynamically compiled when the page is requested. Must be a class name without namespace information.

CompilerOptions

A sequence of compiler command-line switches used to compile the page.

Debug

A Boolean value that indicates whether the page should be compiled with debug symbols.

Explicit

A Boolean value that determines whether the page is compiled with the Visual Basic Option Explicit mode set to On. Option Explicit forces the programmer to explicitly declare all variables. The attribute is ignored if the page language is not Visual Basic .NET.

Inherits

Defines the base class for the page to inherit. It can be any class derived from the Page class. (I'll cover this in Chapter 2.)

Language

Indicates the language to use when compiling inline code blocks (<% … %>) and all the code that appears in the page

When the runat attribute is set to server, all the code comprised between the opening and closing tags is given special meaning. In this case, the code is extracted from the .aspx source file, compiled into an assembly, and then executed when the page runs. No line of this code will ever be output to the client.

When the runat attribute is not included, the content of the

You can use the method DeclareLove from within a <% … %> block. Another difference with ASP concerns variable declarations. In ASP.NET, the variables declared in <% … %> blocks are no longer globally available to other functions and methods in the page; they can be accessed only by code defined in other render blocks on the page.

In ASP, you were used to putting all initialization code at the beginning of the first code block. In ASP.NET, initialization code must be included within the Page_Load method. You can still use ASP-style programming, but keep in mind that all the code in <% … %> blocks will be executed only when the page is rendered, and therefore, after the page is loaded.

Aside from the few but important differences we just mentioned, ASP.NET can run a significant portion of the existing old-style ASP code. For example, the following typical loop produces the same results as in ASP:

<% for (int i=0; i<8; i++) { %> ASP.NET is Love! <% } %>

Figure 1-3 shows the output when you run this code.

Figure 1-3: Programmers' love for ASP.NET grows constantly.

Likewise, you can set any of the properties of the

Note

Some ASP.NET pages can lack the

The markup elements found in the body of the page whose name matches an HTML element are mapped to the corresponding HTML server control. Elements that belong to the namespace are mapped to Web server controls. Other markup elements are mapped to the assembly and class name declared by using an @Register directive.

Pagewide Tags

The runat attribute can be used also with pagewide tags such as

, and

. These tags are represented through an instance of the HtmlGenericControl class. HtmlGenericControl is the .NET class used to represent an HTML server-side tag not directly represented by a .NET Framework class. The list of such tags also includes , , , and.

In the following page, the page title and page background are set programmatically using a server-side object instance:

Click the View|Source menu item...

The resulting HTML code is as follows:

tag, thus deciding programmatically, say, which style sheet to use for the page. You use the HtmlGenericControl's Attributes collection to create attributes on the tag and the InnerText property to set the text. We'll discuss the programming interface of the HtmlGenericControl class in Chapter 3.

Meta Tags

The runat attribute can be applied also to the tag, but a little trick is needed this time. In HTML, you normally add the tag without a closing tag. This is not permitted by ASP.NET when the runat attribute is added. The ASP.NET parser scans the whole file looking for tag; if the tag is not found, a compile error is generated.

The following code shows how to programmatically set meta content that instructs the browser to wait four seconds and then to go to the specified URL:

Pro ASP.NET (Ch 01) Click the View|Source menu item in the next few seconds...

The resulting HTML meta tag is shown below. Notice the fundamental presence of the closing tag:

Note You can also use the Response.AppendHeader method to add an HTTP header to the output stream. The programming interface of the Response object also features an AddHeader method. AddHeader is the same as AppendHeader and is provided only for compatibility with previous versions of ASP. With ASP.NET, you should always use AppendHeader.

Unknown Tags

In case of unknown tags, namely tags that are neither predefined nor user-defined, the ASP.NET runtime can behave in two different ways. If the tag doesn't contain namespace information, ASP.NET treats it like a generic HTML control. The empty namespace, in fact, evaluates to the HTML namespace, thereby leading the ASP.NET runtime to believe the tag is really an HTML element. No exception is raised, and markup text is generated on the server. For example, let's consider the following ASP.NET page:

Click the View|Source menu item...

The tag is still processed as if it was a regular HTML tag, and the FavoriteFood attribute is added. Figure 1-4 shows what the HTML code for this page actually is. In the preceding sample, the type of the dinoe object is HtmlGenericControl.

Figure 1-4: ASP.NET also processes namespace-less custom tags, mapping them to the HtmlGenericControl class.

If the tag does contain namespace information, it is acceptable as long as the namespace is or a namespace explicitly associated with the tag name using an @Register directive. If the namespace is unknown, a compile error occurs.

ASP NET Server Controls

There are basically two families of ASP.NET server controls. They are HTML server controls and Web server controls. System.Web.UI.HtmlControls is the namespace of HTML server controls. System.Web.UI.WebControls groups all the Web server controls.

HTML server controls are classes that represent a standard HTML tag supported by most browsers. The set of properties of an HTML server control matches exactly the set of attributes of the corresponding tag. The control features properties such as InnerText, InnerHtml, Style, and Value and collections such as Attributes. Instances of HTML server controls are automatically created by the ASP.NET runtime each time the corresponding HTML tag marked with runat="server" is found in the page source.

Web server controls are controls with more features than HTML server controls. Web server controls include not only input controls such as buttons and textboxes, but also special-purpose controls such as a calendar, an ad-rotator, a drop-down list, and a data grid. Web server controls also include components that closely resemble some HTML server controls. Web server controls, though, are more abstract than the corresponding HTML server controls in that their object model doesn't necessarily reflect the HTML syntax. For example, let's compare the HTML server text control and the Web server TextBox control. The HTML server text control has the following markup:

The Web server TextBox control has the following markup:

Both controls generate the same HTML code. However, the programming interface of the HTML server text control matches closely that of the HTML tag, while methods and properties of the Web server TextBox control are named in a more abstract way. For example, to set the content of an HTML server text control, you must use the Value property because Value is the corresponding HTML attribute name. If you work with the Web server TextBox control, you must resort to Text. With very few exceptions (which I'll discuss in Chapter 3), using HTML server controls or Web server controls to represent HTML elements is only a matter of preference.

Migrating from ASP to ASP NET

In the past five years, one million developers all over the world have chosen ASP as the development platform of choice to build Web applications. You can bet that with such a huge base of installed applications, the problem of ensuring backward compatibility between ASP and ASP.NET has been taken very seriously. The result is that ASP and ASP.NET applications can run side by side on an IIS Web server without any form of interference occurring. In addition, and in spite of the radical changes in the underlying architecture and implementation, a significant portion of existing ASP pages can just be renamed as .aspx files and will continue working (even a bit faster) and be managed by a different IIS module. Does this really mean you can migrate ASP applications to ASP.NET simply by renaming files? Well, not exactly. As always, code migration is a delicate art that becomes impracticable when huge architectural differences exist between the starting and ending points. ASP.NET is designed to make migration easier, but a migration plan is still needed and a 100 percent pure ASP.NET solution is needed to be really effective.

Side by Side Execution

IIS makes use of the file extension to determine which module has to process a requested resource. As a result, only files with a .aspx extension are served by ASP.NET. All the files with a .asp extension will continue to be served by the existing (and unchanged) ASP engine. Because completely different and independent modules serve ASP and ASP.NET requests, existing ASP applications cannot be corrupted simply by installing and running ASP.NET applications on the same Web server.

Not only can you make ASP and ASP.NET applications live side by side on the same Web server, but—more importantly—you can also manage to create applications that use both ASP and ASP.NET pages. After all, from the perspective of an ASP application, what's a .aspx resource if not a simple URL on the same domain?

Important

Obviously, mixed applications—applications in which ASP and ASP.NET pages run side-by-side—are recommended only if you take an existing, complex ASP application and enhance it with new ASP.NET pages. The opposite approach, although possible, doesn't make sense. If you're engaged on a new ASP.NET project, by all means forget about ASP.

Note, though, that when ASP and ASP.NET pages live within the context of the same application, some restrictions apply. For example, session state and application state are not shared between ASP and ASP.NET pages. In particular, the problem of sharing session state between ASP and ASP.NET applications is fully dissected in an article available at http://msdn.microsoft.com/library/en-us/dnaspp/html/converttoaspnet.asp.

Rewriting ASP Pages as ASP NET Pages

Although far richer and created with different design centers, the new ASP.NET programming model has been kept as close as possible to the old ASP model. As a result, ASP.NET programming might seem familiar to developers with good ASP skills. However, although still available in ASP.NET, the ASP-intrinsic objects have been redesigned to make them more structured and object-oriented, and new objects have been provided.

The net effect is that existing ASP code, albeit accepted and functional, is not necessarily the best way of accomplishing a given task. For example, you can still build a list of check-box items by merging plain HTML text and data-bound information in a string buffer. Nevertheless, using the new CheckBoxList control would result in more compact, safe, readable, and maintainable code. Likewise, using ActiveX Data Objects (ADO) to access a back-end database server is supported, but it might require some changes to the code and would penalize the performance because data destined to COM objects must be marshaled in and out of the .NET Common Language Runtime (CLR). Global data that you stored in the Application object sometimes can be more efficiently stored in the new Cache object, which manages perishable data and automatically garbage-collects it when needed.

These are a few examples of the performance hitches you can unwittingly generate in your ASP.NET pages if you create them to resemble existing ASP pages. But there's another key issue to consider when you plan to rewrite ASP pages as ASP.NET pages—the language. Many existing ASP pages are written with VBScript, but only a small portion of the VBScript syntax is acceptable to the Visual Basic .NET compiler. Those pages will not port directly to ASP.NET and will require changes. The necessary changes will probably be limited to only a few lines of code, but those changes must be applied to all pages in the application.

All in all, adapting existing pages as ASP.NET pages is possible but comes at a cost; and such adaptations will not give you highly optimized code. So what should you do with existing ASP applications?

Suggested Migration Plans

Before continuing with this topic, I need to issue a disclaimer of sorts and mention situations in which migrating to ASP.NET might not be ideal. Understand that ASP.NET—and the subsequent installation of the ASP.NET runtime and the .NET Framework on the Web server—does not affect or compromise existing ASP applications. Existing applications will continue working in the same way and with the same performance as before. Additionally, new and ad hoc designed ASP.NET applications feature far better performance and an improved scalability and programming model. If I had to choose a single word to explain what ASP.NET is all about, that word would be productivity.

ASP.NET-enhanced productivity applies at all levels. You have less code to write (and that code is easier to understand and maintain); a relatively flat learning curve; significant cuts in the cost of the deployment; and a greatly simplified model for localization and customization. ASP.NET is also language-independent and performs much better than ASP. And in my humble opinion, even all that pales in comparison to the gains you experience in productivity.

With that said, I can issue my disclaimer. You probably know better than I do that in this little imperfect world, new projects require new budgets. Upgrading a huge and complex Web site, such as a portal, can be expensive even with the productivity advantages of ASP.NET. If budget is not a concern, then by all means redesign and rewrite the application from scratch. Period. If the budget is a severe concern, you should seriously consider holding off and waiting for better times—the old ASP application will still work. At the very least, the current version of ASP.NET increases your productivity and the application's overall performance, but as of now it can't fit more cheaply into a project's budget! For that to happen, we have to wait for the next version at the earliest.

In between upgrading and not upgrading, I see a few options to move ASP applications towards ASP.NET even when working with relatively small budgets.

Same Application, New Pages

My first suggestion is that you keep the existing ASP application as is and use ASP.NET only if you're required to add new features and new pages. While extremely cost-effective, the plan poses a few development issues because ASP and ASP.NET pages running together can't share the internal state. Aside from this, no other interoperability issues or interference exist between old and new pages.

New Application, Same Framework, New Pages

In this case, you develop a new ASP.NET application but without revisiting and redesigning the application's framework. The skeleton and the functions of the application remain the same. The migration roughly consists of translating the constituent pages from ASP to ASP.NET. Basically, you rename each .asp page to .aspx and adapt it to work.

We already discussed the nature of this approach in the "Rewriting ASP Pages as ASP.NET Pages" section. Here, we provide a more detailed list of the issues you must be ready to face:

Page directives ASP has a rough model for setting up the environment in which the page will run. ASP.NET directives have been designed to be fully compatible with ASP directives. However, in an ASP.NET page you might want to exploit some extra @Page attributes for a more effective compilation (for example, AspCompat, Explicit, and Strict) and certainly for tracing or debugging purposes. Finally, bear in mind that you also need to link extra assemblies if you import .NET wrappers of COM components.

Programming languages ASP pages are normally written with VBScript, but VBScript is scarcely compatible with Visual Basic .NET. You must carefully review the code of all pages and probably replace On Error statements with the more effective .NET exception handling. You must replace the VBScript CreateObject with Server.CreateObject to preserve the syntax to some extent, or choose a different approach and import the COM object through a .NET wrapper class. Pay attention to turn the @Page's AspCompat attribute on if you're using COM and COM+ objects within an ASP.NET page. If the page was written with JScript, things are a bit simpler, as JScript is highly compatible with JScript .NET. However, a careful code review is nevertheless in order.

Code blocks ASP.NET pages support ASP-style code blocks but with some limitation, as explained previously in the "The

,Pro ASP.NET (Ch 01)Click the View|Source menu item...