asp.net|request|解答|问题

Migrating to ASP .NET: Key Considerations

Jim Kieley
Microsoft Corporation
July 2001
Summary: This article explores some basic considerations for moving existing ASP applications to the ASP .NET environment as quickly and efficiently as possible. (18 printed pages)

Contents

Introduction
Compatibility Issues
Core API Changes
Structural Changes
Visual Basic Language Changes
COM-Related Changes
Application Configuration Changes
State Management
Security-Related Changes
Data Access
Preparation for ASP .NET
Summary

Introduction

Although the designers of Microsoft® ASP .NET have done an excellent job in preserving backward compatibility with ASP applications, there are a few key items you need to be aware of before undertaking the effort of moving a Web application from ASP to ASP .NET. A solid understanding of the technologies that have changed or been introduced with the .NET platform and ASP .NET will go a long way in making this process a whole lot easier.
This article explores a number of areas of change to give a clear understanding of the efforts involved in getting an ASP application up and running in the ASP .NET environment. At the same time, it points out some of the new features of ASP .NET that can be leveraged to improve an existing application. This is by no means a comprehensive look at all of the new features in ASP .NET. Instead, it focuses on areas that you need to know now for successful migration.
I am assuming that since the majority of ASP applications use Microsoft® Visual Basic® Scripting Edition (VBScript), most of you will elect to migrate to ASP .NET using Visual Basic .NET. This is obviously not a requirement, but changing languages at the same time you decide to migrate will take some additional effort and most likely will include design and architectural changes as well.

Coexistence

Before we get into discussing specific compatibility and migration issues, it is important that you understand how ASP and ASP .NET can coexist. Both ASP and ASP .NET applications can run side by side on a server without adversely affecting each other. This is primarily due to the fact that separate file extensions (.asp versus .aspx) and separate configuration models (metabase/registry versus XML-based configuration files) are used between the two technologies. The two systems have totally separate processing engines.
It is entirely possible to have part of one application running ASP and another part of the same application running ASP .NET. This is very beneficial if you need to move a large, rapidly changing site to ASP .NET one piece at a time. Some would argue that you may be better off porting and deploying the entire site all at once. This may be the case for certain classes of Web applications, but I think that there are a lot of sites out there where this may not be feasible due to the sheer size, complexity, and rapid evolution of the site's content and presentation. After all, if you are sitting on a profitable Web site, chances are the people paying the bills will not allow you to stop implementing their new features so that you can move things over to this hot new technology. Additionally, if you are going to put forth the effort to move to ASP .NET as a long-term investment, you will want to use this chance to make as many architectural and design improvements as you can. For these types of situations, coexistence using a phased-in approach is an absolute must.

Compatibility Issues

Migrating your application to ASP .NET may not be easy; however, it should not be that difficult either. ASP .NET is very much compatible with ASP. This is impressive given the fact that ASP .NET is a complete overhaul of ASP. The designers of ASP .NET had an initial goal of being 100 percent backwards compatible with ASP but subsequently had to back off this goal in favor of improving the platform for the long haul. Not to worry—the changes made were for the better and should not require a lot of work on your part to implement. The actual changes made can be categorized into the following sections:

• Core API changes
• Structural changes
• Visual Basic language changes
• COM-related changes
• Application configuration changes
• State management issues
• Security-related changes
• Data access

Each of these areas will be discussed in detail.

Core API Changes

The core APIs of ASP consist of a few intrinsic objects (Request, Response, Server, etc.) and their associated methods. With the exception of a few simple changes, these APIs continue to function correctly under ASP .NET. All of the changes are related to the Request object and are shown in Table 1:
Table 1. API ChangesMethodChangeRequest(item)In ASP, this method will return an array of strings. In ASP .NET, it returns a NameValueCollection.Request.QueryString(item)In ASP, this method will return an array of strings. In ASP .NET, it returns a NameValueCollection.Request.Form(item)In ASP, this method will return an array of strings. In ASP .NET, it returns a NameValueCollection.
As you can see, the changes are basically the same for all methods involved.
If the item you are accessing contains exactly one value for the specified key, you do not need to modify your code. However, if there are multiple values for a given key, you need to use a different method to return the collection of values. Also, note that collections in Visual Basic .NET are zero-based, whereas the collections in VBScript are one-based.
For example, in ASP the individual query string values from a request to http://localhost/myweb/valuetest.asp?values=10&values=20 would be accessed as follows:

<%   'This will output "10"   Response.Write Request.QueryString("values")(1)   'This will output "20"   Response.Write Request.QueryString("values")(2)%>

In ASP .NET, the QueryString property returns a NameValueCollection object from which you need to retrieve the Values collection before retrieving the actual item you want. Again, note the first item in the collection is retrieved by using an index of zero rather than one:

<%   'This will output "10"   Response.Write (Request.QueryString.GetValues("values")(0))   'This will output "20"   Response.Write (Request.QueryString.GetValues("values")(1))%>

In both the case of ASP and ASP .NET, the follow code will behave identically:

<%   'This will output "10", "20"   Response.Write (Request.QueryString("values"))%>

Structural Changes

Structural changes are those that affect the layout and coding style of Active Server Pages. You need to be aware of several of these to ensure your code will work in ASP .NET.

Code Blocks: Declaring Functions and Variables

In ASP, you can declare subroutines and global variables in between your code delimiters.

<%   Dim X   Dim str   Sub MySub()      Response.Write "This is a string."   End Sub  %>

In ASP .NET, this is no longer allowed. You must instead declare all of your functions and variables inside a <script> block.

<script language = "vb" runat = "server">   Dim str As String   Dim x, y As Integer   Function Add(I As Integer, J As Integer) As Integer      Return (I + J)   End Function</script>

Mixing Programming Languages

In ASP, you basically have two choices for your programming language: VBScript or Microsoft® JScript®. You are free to mix and match blocks of script in the same page at will.
In ASP .NET, you currently have three options. You can use C#, Visual Basic .NET, or JScript. Note that I said Visual Basic .NET instead of VBScript. This is because VBScript does not exist in the .NET platform. It has been fully subsumed by Visual Basic .NET. Although you are free to pick any of these languages, it is important to note that you cannot mix languages on the same page as you could do in ASP. It is certainly possible to have Page1.aspx of your application contain C# code while Page2.aspx of the same application contains Visual Basic .NET code. You just cannot mix them together in a single page.

New Page Directives

In ASP you must place all directives on the first line of a page within the same delimiting block. For example:

<%LANGUAGE="VBSCRIPT" CODEPAGE="932"%>

In ASP .NET, you are now required to place the Language directive with a Page directive, as follows:

<%Page Language="VB" CodePage="932"%><%QutputCache Duration="60" VaryByParam="none" %>

You can have as many lines of directives as you need. Directives may be located anywhere in your .apsx file but standard practice is to place them at the beginning of the file.
Several new directives have been added in ASP .NET. I encourage you to look these up in the ASP .NET documentation to see how they may benefit your application.

Render Functions Are No Longer Valid

In ASP, developers figured out that they could do clever things by using what is termed a "Render Function." A Render Function is basically a subroutine that contains chunks of HTML embedded throughout its body. For example:

<%Sub RenderMe()%><H3> This is HTML text being rendered. </H3><%End SubRenderMe%>

Although you can do some cool things using these types of functions, this type of coding is no longer allowed in ASP .NET. This is probably for the better. I am sure you have seen functions that quickly become unreadable and unmanageable when you start to mix and match code and HTML like this. The simplest way to make this work in ASP .NET is to replace your HTML outputs with calls to Response.Write as follows:

<script language="vb" runat="server">   Sub RenderMe()      Response.Write("<H3> This is HTML text being rendered. </H3>")   End Sub</script><%   Call RenderMe()%>

Note that I said "simplest way." This does not necessarily mean it is the best way. Depending on the complexity and amount of your rendering code, it may be beneficial for you to look into using custom Web controls, which allow you to programmatically set your HTML attributes and truly separate your code from your content. Doing so makes for much more readable code.

Visual Basic Language Changes

As I mentioned earlier, VBScript has been deprecated in favor of the more complete and more powerful Visual Basic .NET. In this section, I will highlight some of the issues you are likely to encounter related to Visual Basic language changes. It is important to note that this is not meant to be an exhaustive list of all of the changes made to Visual Basic. Instead, I have focused on the items that you as an ASP/VBScript programmer will likely encounter moving to ASP .NET using Visual Basic .NET. Consult the Visual Basic .NET documentation for a complete list of all language changes that have been made.

Farewell to the Variant Data Type

We know it, we love it, we love to hate it. I am speaking of a VARIANT data type, of course. VARIANTs are not a part of .NET and thus are not supported in Visual Basic .NET. What this means is that all of your ASP variables are silently going to move from VARIANT types to Object types. Most variables used in your application can and should be changed to a corresponding primitive type depending on your needs. If your variable is really an object type in Visual Basic terms, simply explicitly declare it as an Object type in ASP .NET.

Visual Basic Date Type

One VARIANT type that warrants some special attention is the VT_DATE type, which manifests itself in Visual Basic as a Date type. In Visual Basic, a Date is stored in a Double format using four bytes. In Visual Basic .NET, Date uses the Common Language Runtime DateTime type, which has an eight byte integer representation.
Since everything is a VARIANT in ASP, your intended Date variables will compile and may continue to work depending on how they are used. It is possible, however, that you will run into some unexpected problems performing certain operations with the variable because the underlying type has been changed. Pay attention to areas where you may be passing the date value into COM objects as long integer values or performing certain casting operations on date types using CLng.

Option Explicit Is Now the Default

In ASP, the Option Explicit keywords were available but were not enforced as the default. In Visual Basic .NET, this has changed. Option Explicit is now the default so all variables need to be declared. It is good practice to be even more rigid than this and change your setting to Option Strict. Doing so forces you to declare all of your variables as a specific data type. While this may seem like extra work, it really is the way you should be doing things anyway. If you choose not to, your code will be less than optimal as all undeclared variables will become Object types. Most implicit conversions will still work, but you will probably be better off and safer if you explicitly declare all of your variables to the types you want them to be.

LET and SET Are No Longer Supported

Objects can be assigned to one another directly like this: MyObj1 = MyObj2. You no longer need to use the SET or LET statements. If you use these statements, they must be removed.