Migrate to ASP. NET: Important issues to consider

Introduction to the problem
While the designers of microsoft®asp. NET have done a great deal of effort to keep backward compatibility of ASP applications, there are several key issues to be aware of before migrating WEB applications from ASP to ASP. The improvement of existing technologies in the. NET platform and ASP. NET and the adoption of new technologies to make a thorough understanding of these technologies can help simplify this migration process, but it will take a long time.

This article explores changes in all aspects to give users a clear idea of the work that must be done to build an ASP application and run it in the ASP. NET environment. It also points to some of the new features of ASP. NET, which allows users to make the most of these new features to improve existing applications. This is by no means an overview of all the new features of ASP. NET, but focuses on some of the issues that need to be considered when migrating successfully.

I assume that because most ASP applications use microsoft®visual basic®scripting Edition (VBScript), most users will choose to migrate to ASP. NET using Visual Basic. Net. Obviously, this is not necessary. However, if you decide to change the language at the same time as you migrate, you will need to do some extra work, and it is likely to involve design and architectural changes.

Coexistence of
Before discussing specific compatibility and migration issues, it is important to understand how ASP and ASP. ASP and ASP. NET applications can run on the server at the same time without affecting each other. This is mainly due to the fact that both technologies use different file extensions (. asp and. aspx) and different configuration models (configuration database/registry and xml-based configuration file). The two systems also have corresponding processing engines.

It is entirely possible to have one part of an application run ASP, while the other is running ASP. This feature will be of great benefit to you if you need to migrate a small, fast-growing large site to ASP. NET at a time. Some users may say it is best to migrate and deploy the entire site at once. This may be true for some types of Web applications, but I think there are many sites that do not: considering the absolute size, complexity, and rapid change in the content and appearance of the site, this is a very inflexible approach. After all, for a profitable web site, the people who pay for it are unlikely to allow you to stop their new features and migrate the entire site to this popular new technology. In addition, if you are using ASP. NET migration as a long-term investment, you will want to take this opportunity to make as many architectural and design improvements as possible. In synthesizing these conditions, a phased coexistence migration is absolutely necessary.

Compatibility issues
Migrating an application to ASP. NET migration may not be an easy task, but it shouldn't be difficult. ASP. NET compatibility with ASP is very good, to the user feel like ASP. NET is a complete replica of ASP. The original goal of the ASP. NET designers was to achieve total backward compatibility with ASP, but in the ensuing work they had to change that intent in order to improve the platform thoroughly. But don't worry, we've made a lot of improvements as much as we can, and we shouldn't need you to do too much work. The actual changes that occur can be grouped into the following categories:

Changes to the core API
Structural changes
Changes in Visual Basic language
COM-related changes
Changes to application Configuration
State management issues
Security-related changes
Data access
The changes in each of these areas are discussed in detail below.

Changes to the core API
The core API of ASP consists of several intrinsic objects (Request, Response and Server, etc.) and its related methods. In addition to a few simple changes, these APIs continue to function under ASP. NET. All changes are related to the Request object, as shown in table 1:

Changes in table 1:api

Method changes
Request (item) in ASP, this method returns an array of strings. In ASP. NET, it returns NameValueCollection.
Request.QueryString (item) in ASP, this method returns an array of strings. In ASP. NET, it returns NameValueCollection.
Request.Form (item) in ASP, this method returns an array of strings. In ASP. NET, it returns NameValueCollection.

As you can see, the changes are basically the same for all the methods involved.

If the Access item (item) contains only one value for a particular keyword, you will not have to modify your own code. However, if a given keyword has more than one value, you will need to return a collection of values using other methods. Also note that the collections in Visual Basic. NET are based on 0, while the collections in VBScript are based on 1.

For example, in ASP, the individual query string values returned by the HTTP://LOCALHOST/MYWEB/VALUETEST.ASP?VALUES=10&VALUES=20 request are accessed in the following manner:

<%
' Output ' 10 '
Response.Write Request.QueryString ("Values") (1)

' Output ' 20 '
Response.Write Request.QueryString ("Values") (2)
%>

In ASP. NET, the QueryString property returns a NameValueCollection object that will need to retrieve Values from the object before retrieving the actual item you want