A Free Trial That Lets You Build Big!
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
Although Microsoft®ASP. NET designers have made a lot of unremitting efforts to maintain the backward compatibility of ASP applications, but they are moving Web applications from ASP to ASP. NET migration, you should understand several key issues. On the. NET platform and ASP. NET platform, the existing technologies have been improved and some new technologies have been adopted. A thorough understanding of these technologies helps simplify the migration process, but it takes a long time.
This article discusses the changes in various aspects, so that users can clearly understand the necessary work to establish an ASP application and make it run in the ASP. NET environment. At the same time, it also points out some new ASP. NET features, users can make full use of these new features to improve existing applications. However, this is by no means a comprehensive introduction of all the new features of ASP. NET, but focuses on some issues that need to be considered when a successful migration.
I imagine that most ASP applications use Microsoft®Visual Basic®Scripting Edition (VBScript), so most users 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 the migration, some additional work will be required, and it may also involve design and structural changes.
Before discussing specific compatibility and migration issues, it is very important to know how ASP and ASP. NET coexist. ASP and ASP. NET applications can run on the server at the same time without affecting each other. This is mainly because the two technologies use different file extensions. asp and. aspx respectively) and different configuration models to configure the database/Registry and XML-based configuration files ). The two systems also have corresponding Processing engines.
It is entirely possible to run ASP in one part of an application and ASP. NET in the other. If you want to migrate a rapidly growing large site to ASP. NET in a small part at a time, this feature will be of great benefit to you. Some users may say that it is best to migrate and deploy the entire site at one time. This may be the case for some types of Web applications, but I think many websites do not: Considering the absolute size, complexity, and rapid changes of site content and appearance, this method lacks flexibility. After all, for a profitable website, it is impossible for those who pay for it to allow you to stop their new features and migrate the entire website to this popular new technology. In addition, if you migrate to ASP. NET as a long-term investment, you will want to take advantage of this opportunity to make as many improvements to the structure and design as possible. Based on these situations, it is absolutely necessary to perform a staged co-existence migration.
Migrating applications to ASP. NET may not be easy, but it should not be difficult. The compatibility between ASP. NET and ASP is very good, giving users the feeling that ASP. NET is a complete version of ASP. The initial goal of ASP. NET designers was to achieve backward compatibility with ASP, but they had to change the original intention in subsequent work to thoroughly improve the platform. But don't worry. We have made a lot of improvements as much as possible, so we shouldn't need you to do too much work. The actual changes can be summarized into the following categories:
Core API changes
Changes in Visual Basic
Application configuration changes
Status Management Problems
The changes in the above aspects will be discussed in detail below.
Core API changes
The core API of ASP is composed of several inherent objects, such as Request, Response, and Server. Except for a few simple changes, these Apis can continue to run normally under ASP. NET. All changes are related to the Request object, as shown in table 1:
Table 1: API changes
Request (item) in ASP, this method returns a string array. In ASP. NET, it returns NameValueCollection.
Request. QueryString (item) in ASP, this method returns a string array. In ASP. NET, it returns NameValueCollection.
Request. Form (item) in ASP, this method returns a string array. In ASP. NET, it returns NameValueCollection.
As you can see, all the methods involved are basically the same.
If the accessed item) only contains a value for a specific keyword, you do not have to modify your own code. However, if a given keyword has multiple values, you need to use a set of other methods to return values. Note that the Set in Visual Basic. NET is based on 0, while the set in VBScript is based on 1.
For example, in ASP, access http: // localhost/myweb/valuetest. asp? Values = 10 & values = 20 query string values returned by the request:
Response. Write Request. QueryString ("values") (1)
Response. Write Request. QueryString ("values") (2)
In ASP. NET, The QueryString attribute returns the NameValueCollection object. The Values set needs to be retrieved from the object before the actual items are retrieved. In addition, you must note that the first item in the set is retrieved using 0 instead of 1 Index:
Response. Write (Request. QueryString. GetValues ("values") (0 ))
Response. Write (Request. QueryString. GetValues ("values") (1 ))
The following code runs the same result in ASP and ASP. NET:
'Output "10" and "20"
Response. Write (Request. QueryString ("values "))
Structural changes will affect the layout and encoding style of Active Server Pages. You need to know some information to ensure that your code can run in ASP. NET.
Code block: declare functions and variables
In ASP, subprograms and global variables can be declared between code delimiters.
Sub MySub ()
Response. Write "this is a string. "
In ASP. NET, declarations cannot be made in this way. You must
Hybrid Programming Language
In ASP, there are basically two programming languages for you to choose from: VBScript or Microsoft®JScript®. On the same webpage, you can combine and match various script blocks at will.
There are currently three languages available in ASP. NET: C #, Visual Basic. NET, or JScript. Note: I am talking about Visual Basic. NET, not VBScript. This is because VBScript does not exist on the. NET platform and has been fully integrated into Visual Basic. NET. Although you can select any language, you must note that you cannot use multiple languages in the same web page as in ASP. You can indeed use C # code in Page1.aspx of the same application, and use Visual Basic. NET code in Page2.aspx, but you cannot mix them on the same page.
New Page command
In ASP, all commands must be placed in the first line of the same separator block in the web page. For example:
<% LANGUAGE = "VBSCRIPT" CODEPAGE = "932" %>
In ASP. NET, replace the Language command with the Page Command, as shown below:
<% @ Page Language = "VB" CodePage = "932" %>
<% @ QutputCache Duration = "60" VaryByParam = "none" %>
You can include any number of lines of commands as needed. Commands can be anywhere in the. apsx file, but the standard practice is to place them at the beginning of the file.
Several commands are added to ASP. NET. I encourage you to view these commands in the ASP. NET document to learn about the benefits they can bring to your application.
The generated function is no longer valid.
Developers pointed out that in ASP, they can use "generate functions" to flexibly handle some problems. The "generate function" is basically a sub-program, which embeds a large number of HTML in its body. For example:
<% Sub RenderMe ()
This is the HTML text being generated.
<% End Sub
Although the use of such functions can implement very cool functions, such encoding is not allowed in ASP. NET. This may be due to performance optimization considerations. I think you must have met some functions that are very readable and difficult to manage when code and HTML are mixed like this. In ASP. NET, the simplest way to achieve this is to call Response. Write to replace HTML output, as shown below:
Call RenderMe ()
Note: I am talking about the "simplest method", but it does not necessarily mean it is the best method. Depending on the complexity and quantity of the generated code, using a custom Web control may have a better effect. This control allows you to set HTML attributes through programming and truly separate the code from the content, make the code more readable.
Changes in Visual Basic
As I mentioned earlier, VBScript has been integrated into Visual Basic. NET, which is more complete and powerful. In this section, I will focus on some issues you may encounter related to Visual Basic language changes. Note that this is not a detailed list of Visual Basic changes. As an ASP/VBScript programmer, I only focus on some problems that may occur when using Visual Basic. NET to migrate data to ASP. NET. For a detailed list of all language changes, see the Visual Basic. NET documentation.
Farewell to Variant Data Type
We are familiar with it, like it, love it and hate it. Of course, I am talking about the VARIANT data type .. . NET does not have VARIANT, so Visual Basic. NET does not support this data type. This means that all your ASP variables will be quietly changed from the VARIANT type to the Object type. As needed, a large number of variables used in the application can and should be changed to the corresponding primitive type. If your variable is actually of the object type in Visual Basic, you only need to explicitly declare it as the Object type in ASP. NET.
Visual Basic Date type
It is worth noting that the VARIANT type is VT_DATE, which appears in Visual Basic as Date. In Visual Basic, four bytes are used to store the Date in Double format. In Visual Basic. NET, Date uses the DateTime type of the Common Language Runtime Library, which is represented by eight byte integers.
Because all types in ASP are VARIANT, the required Date variables are compiled based on their usage and can be used again. However, when you use a variable to perform some operations, unexpected problems may occur because the basic type has changed. When passing a date value as a long integer value to a COM object, or using CLng to perform some calculations on the date type, pay special attention to it.
Option Explicit is the default value.
In ASP, you can use the Option Explicit keyword, but it is not the default value. In Visual Basic. NET, the situation varies. Option Explicit is now the default value. Therefore, all variables must be declared. It is wise to require more Strict declarations and change the settings to Option Strict. This forces you to declare all variables as specific data types. At first glance, this is an extra job, but it is actually the right way to do things. If you do not do this, your code will not reach the optimal state, because all undeclared variables will be changed to the Object type. Most of the implicit conventions are still valid, but if all variables are explicitly declared as the desired type, they can achieve better results and be safer.
No longer supports LET and SET
You can assign an object to another object directly, for example, MyObj1 = MyObj2, instead of using the SET or LET statement. If you use these statements, you must delete them.
Use parentheses in method calls
In ASP, you can call the object method at will without using brackets, as shown below:
Sub WriteData ()
Response. Write "This is data"
In ASP. NET, brackets must be used for all calls, even if the call does not contain any parentheses. As shown in the following example, you can write code to make it run correctly in ASP and ASP. NET.
Sub WriteData ()
Response. Write ("This is data ")
Call WriteData ()
ByVal is the default value.
In Visual Basic, all parameters are passed by reference or ByRef by default. In Visual Basic. NET, the situation varies. By default, all parameters are passed through values or ByVal. If you still want to use ByRef, you must explicitly use the ByRef keyword before the parameter, as shown below:
Sub MyByRefSub (ByRef Value)
Value = 53;
Pay special attention to this. When migrating code to ASP. NET, it is recommended that you carefully check each parameter used in the method call to ensure that this change is what you really need. I think you may need to change some of these parameters.
No Default attributes
In Visual Basic. NET, the default attribute concept does not exist. This means that if your ASP code depends on the default attribute provided by an object, you need to change it to explicitly reference the required attribute, as shown in the following code:
'Asp syntax implicitly retrieves Column Value attributes)
Set Conn = Server. CreateObject ("ADODB. Connection ")
Conn. Open ("TestDB ")
Set RS = Conn. Execute ("Select * from Products ")
Response. Write RS ("Name ")
'Asp. NET syntax display and retrieval of Column Value attributes)
Conn = Server. CreateObject ("ADODB. Connection ")
Conn. Open ("TestDB ")
RS = Conn. Execute ("Select * from Products ")
Response. Write (RS ("Name"). Value)
Changes in data types
In Visual Basic. NET, the Integer value is now 32 bits, and the Long type has changed to 64 bits.
When you call the COM Object method from ASP. NET, or call the Microsoft®Win32®Problems may occur when calling APIs. Pay special attention to the actual data types required to ensure that the passed or calculated values are correct.
Structured Exception Handling
Although the familiar On Error Resume Next and On Error Goto Error handling technologies are still available in Visual Basic. NET, they are no longer the best method for Error handling. Visual Basic now has a complete method for handling structured exceptions. It uses the Try, Catch, and Finally keywords. If possible, you should migrate to this new mode for error handling because it has a more powerful and consistent application error handling mechanism.
With the advent of the. NET Framework and ASP. NET, COM has not actually changed. However, this does not mean that you do not have to worry about or consider their behavior when using COM objects in ASP. NET. You must understand the basic information.
Thread mode changes
The ASP. NET thread mode is a multi-threaded unit (MTA ). This means that, for components currently created for a Single-threaded unit (STA), they cannot be reliably executed or run in ASP. NET without taking additional measures. These include but are not limited to all COM components created using Visual Basic 6.0 and earlier.
You will be glad to hear that you can still use these STA components without changing any code. All you need to do is include the compatibility attribute aspcompat = true in the <% @ Page> tag of the ASP. NET webpage, for example, <% @ Page aspcompat = true Language = VB %>. Using this property forces the webpage to run in STA mode to ensure that your components continue to run correctly. If you try to use the STA component but do not specify this flag, an exception will occur during running.
When the value of this attribute is set to true, the webpage is allowed to call the COM + 1.0 component. This component needs to access non-managed ASP built-in objects. It can be accessed through the ObjectContext object.
If you set the value of this tag to true, the performance will decrease slightly. We recommend that you do this only when necessary.
Early binding and later binding
In ASP, all calls to COM objects are performed through the IDispatch interface. This behavior is called "post-binding" because calls to actual objects are indirectly processed through IDispatch at run time. In ASP. NET, you can continue to call your components in this way as long as you want.
Dim Obj As Object
Obj = Server. CreateObject ("ProgID ")
You can still access your components in this way, but this is not the preferred method. Now, in ASP. NET, you can use the early binding to directly create an object, as shown below:
Dim Obj As New MyObject
MyObject. MyMethodCall ()
Early binding allows you to interact with components in a type-safe manner. To use early binding in COM components, you need to add a reference to the project just like adding a COM reference to the Visual Basic 6.0 Project. If you are using Visual Studio. NET, a managed proxy object will be created in the background on top of the COM component, which gives you the feeling that you are directly processing a. NET Component, not a COM component.
Now, you may worry about performance issues. An additional layer is introduced as a proxy object, so there are some problems when using COM for collaborative operations. However, in most cases, there should be no problems, because the actual number of CPU commands for collaborative operations is still far smaller than the indirect IDispatch call requirements. What you get will far exceed what you lose. Of course, it is ideal to use the newly created management object, but we know that this is not always possible because of our limited investment in COM components.
OnStartPage and OnEndPage Methods
Pay special attention to the use of the old OnStartPage and OnEndPage methods. If you rely on these methods to access inherent ASP objects, you will need to use the ASPCOMPAT command and Server. CreateObject to create components in the early binding mode, as shown below:
Dim Obj As MyObj
Obj = Server. CreateObject (MyObj)
Obj. MyMethodCall ()
Note that "ProgID" is not used, but the actual type is used in early binding mode. To make this method effective, you need to add COM component reference to the Visual Studio project to create the packaging class that was bound earlier. This is the only situation where you must continue to use Server. CreateObject.
Table 2 summarizes the work that must be done to continue using the COM component effectively.
Table 2: ASP. NET settings for old COM objects
COM component type/method ASP. NET setting/process
Custom Visual Basic components or other components marked as "Apartment" by STA) Use ASPCOMPAT and early binding
Custom MTA is an ATL or custom COM component marked as "Both" or "Free". ASPCOMPAT is not used and early binding is used.
Inherent object access through ObjectContext) Use ASPCOMPAT and early binding
OnStartPage and OnEndPage use ASPCOMPAT and Server. CreateObject (Type)
These settings are also applied regardless of whether your components are deployed in COM +.
Application configuration changes
In ASP, all Web application configuration information is stored in the system registry and IIS configuration database. Because appropriate management tools are often not installed on the server, it is very difficult to view or modify the settings. ASP. NET introduces a complete set of configuration models based on simple and easy-to-read XML files. Each ASP. NET application has its own Web. Config file, which is located in the main application directory. You can use this file to control the custom configuration, behavior, and security of Web applications.
If you are the same as me, You may check and change the settings of ASP. NET applications through the "Internet Service Manager" snap-in. However, you must understand that we now have two completely different configuration models. Except for some security settings, ASP. NET applications will ignore most of the other settings configured using the IIS management tool. You need to save these configuration settings in the Web. Config file.
The configuration of. NET applications will be discussed in detail in another article, which is not described here. Table 3 illustrates some more meaningful settings that can be configured in your own files. Remember, there are more settings.
Table 3: Web. Config setting example
Configure custom application settings.
Configure ASP. NET authentication support.
Identifies the specific configuration settings of the webpage.
Configure ASP. NET process model settings in IIS.
Specifies the session status option.
Some other classes are available in the. NET basic class library, which simplifies programming access to these settings.
If the Application uses Session or the inherent object storage status information of the Application, you can continue to use these objects in ASP. NET without any problems. The advantage is that more options are available for storing status data.
Status Management Options
ASP. NET also contains some other state management model options, which allow you to manage more than one Web server and support State management through the Web farm.
In the web. config file The configuration status management options in this Section are as follows:
Mode = "Inproc"
StateConnectionString = "tcpip = 127.0.0.1: 42424"
SqlConnectionString = "data source = 127.0.0.1; user id = sa; password =" cookieless = "false"
Timeout = "20"
The mode attribute specifies where the status information will be stored. Available options include Inproc, StateServer, SqlServer, or Off.
Table 4: session state storage Information
Inproc session state is locally stored in the ASP style on this server ).
StateServer session status is stored remotely or locally.
The SQL Server session status is stored in the SQL Server database.
The Off session status is disabled.
If one of these options is used, StateConnectionString and sqlConnectionString will undoubtedly become crucial parameters. Each application can only use one storage option.
Store COM components
Note that if you rely on the storage reference of the old COM component in the Session or Application object, you will not be able to use the new state storage mechanism StateServer or SqlServer in the Application ). You will need to use Inproc. This is partly because the object needs to implement self-serial in. NET. Obviously, the COM component cannot do this. On the other hand, the newly created management component can achieve this relatively easily, so you can use the new state storage mode.
Of course, in terms of performance, each step forward will have a corresponding price. However, you can fully believe that, in most cases, using Inproc is still the best choice, followed by StateServer and SqlServer. You should test the application to ensure that the selected options can achieve your performance goals.
Sharing status between ASP and ASP. NET
Another important issue to consider is that although an Application can contain both ASP and ASP. NET web pages, you cannot share the state variables stored in the inherent Session or Application object. You may need to copy the information to these two systems or propose other custom solutions to fully migrate your applications. The best case is that you do not use the Session and Application object. On the other hand, if you use a large number of these objects, You need to always be careful, maybe you can propose a custom short-term solution to share the status.
Security is another important issue that requires special attention. The following briefly introduces the ASP. NET security system. For more information about security, see ASP. NET security document.
ASP. NET security is mainly controlled by the security settings in the web. config file. ASP. NET works with IIS to provide a complete model for your applications. IIS security settings are a few application settings that are actually carried and applied to ASP. NET applications. They are carried in a similar way as ASP. NET. Of course, improvements have been made in many aspects.
For authentication, ASP. NET supports the options shown in table 5.
Table 5: ASP. NET authentication options
Windows ASP. NET uses Windows authentication.
Forms custom login Forms based on cookies.
Passport is not a Passport Service provided by Microsoft.
None does not perform authentication.
All other options except the new Passport authentication options are the same as those in ASP. For example, the following configuration enables Windows-based authentication for the application.
After the user passes authentication, they will focus on the resources they are allowed to access. In the following example, the "jkieley" and "jstegman" access permissions are granted, and all others are denied access.
As a refresh program, simulation refers to a process in which an object executes code with the identifier of the entity it represents. In ASP, the simulation allows your code to run on behalf of authenticated users. Alternatively, you can run it anonymously with a specific identifier. By default, ASP. NET does not simulate each request. This is different from ASP. If you rely on this function, you need to enable it in the web. config file, as shown below:
Another key issue that needs to be considered during migration is data access. With the advent of ADO. NET, you now have a powerful new way to access data. Since data access is a big topic, this article will not discuss it in detail. In most cases, you can continue using ADO as before, but I strongly recommend that you understand ADO. NET and use it to improve data access methods in ASP. NET applications.
Prepare to migrate to ASP. NET
Now that you know most of the problems you may encounter, you may wonder: what preparations do I need to prepare for future migration to ASP. NET? At present, several tasks need to be completed to ensure the smooth migration process in the future. Many of these suggestions are of great benefit to your ASP code, even if you do not plan to migrate to ASP. NET.
Use Option Explicit
This is always a good suggestion, but so far many people have not used it. By using Option Explicit, you can force variables to be declared in ASP. You can at least control where each object is defined and how variables are used. After migrating to ASP. NET, we recommend that you use Option Strict. In Visual Basic. NET, Option Explicit is used by default, but Option Strict is more mandatory to ensure that all variables are declared as correct data types. This does require additional work, but in the long term, you will find it worthwhile to do so.
Avoid using default properties
We have discussed earlier that the default attribute is no longer allowed. Explicit attribute access is not difficult. It enhances code readability and saves you time in the future.
Use brackets and Call keywords
As discussed in detail earlier in this article, use parentheses and Call statements as much as possible. In ASP. NET, parentheses are forcibly used. Now you can use the Call statement to familiarize yourself with some rules and lay a solid foundation for future work.
Avoid nested inclusion files
This may be easy to say, but we should try to avoid nesting include files. I mean, efforts should be made to avoid including other contained files in the contained files. Over time, you may encounter a situation where your Code no longer depends on the global variables defined in other include files, you only need to access the file because it contains another file containing the global variables you actually need.
To ASP. NET migration, you are likely to migrate global variables and programs to the class library. In this case, if you have a clear understanding of the access location of each object, it is easy to migrate. You do not need to move objects or change the same program names in multiple files.
Merge utility functions into a single file
A policy during the migration process is to migrate all the practical functions and code contained in the file on the server to Visual Basic or C # class library. In this way, you can put all the code into the object, which is different from ASP files with multiple interpretations. Organize the code in advance to save the migration time in the future. Theoretically, you should be able to combine subprograms into logical files so that you can easily create a set of VB or C # classes. These functions may be located in the COM object.
If the server contains a large number of global variables or constants in the file, it is best to combine them into a single file. Once you migrate to ASP. NET, you can easily create a class to store global or constant data. This will make the system clean and easier to maintain.
Try to separate code from content
This is easier to say than doing, but you should try to separate the code from the HTML content. Clean up the functions in the entity that have code and scripts. In this way, you can take full advantage of the Code, which is the best mode in ASP. NET.
Do not declare a function in <%> block.
ASP. NET does not support block declaration functions in <%>.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service