ASP TO ASP.NET MIGRATION ISSUES
3. REFERENCES
|
|
|
1. Changing the extension of an ASP page to an ASP.NET extension is the first step in upgrading.
|
|
2. 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" %>
|
|
3. 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>
|
|
4. The most common change required removing the Set statement when assigning an object reference to a variable in ASP code.
Objects can be assigned to one another directly like
this:
The .NET Framework and the underlying common language runtime (CLR) treat everything as an object, eliminating the need for the Set keyword. The following ASP code from the original site 'create the feedback object set oFeedback = Server.CreateObject("BetaSiteMgr.Feedback")
was converted to: 'create the feedback object oFeedback = Server.CreateObject("BetaSiteMgr.Feedback")
|
|
5. Explicitly specify an object's default properties when
referenced in an ASP page. The CLR and ASP .NET removed support for
parameter-free default properties. Unfortunately, even though explicitly
specifying property values makes for more readable and maintainable code,
many developers like to take advantage of default properties and save the
typing. On the Web site, default properties were used most frequently when
working with 'set rs fields rsLameError("BetaID") = Request.Form("betaid") rsLameError("UserDescription") = Request.Form("bugDescription") rsLameError("SeverityID") = Request.Form("severity") were converted in the following manner during the migration: 'set rs fields rsLameError("BetaID").Value=Request.Form("betaid") rsLameError("UserDescription").Value=Request.Form("bugDescription") rsLameError("SeverityID").Value=Request.Form("severity")
|
|
6. Change the way data type conversion functions were used. In ASP .NET, the VBScript data type conversion functions have been moved into the .NET Framework. This change required that ASP code such as the following adoRS.fields("AreaID") = clng(oUploadManager.Form("cboArea")) adoRS.fields("SubAreaID") = clng(oUploadManager.Form("cboSubArea")) be converted during the migration to look like this: adoRS.fields("AreaID").Value = oUploadManager.Form("cboArea").ToString().ToInt()adoRS.fields("SubAreaID").Value = oUploadManager.Form("cboSubArea").ToString().ToInt()
|
|
7. Slightly alter calls to the Response.Write method to adhere to the ASP .NET method call format. In VBScript, procedures that do not return a value can be called without placing the procedure's parameters in parentheses. ASP .NET requires that parameters to all method calls, even those that don't return a value, be enclosed in parentheses. In the original site, it was common to find areas where the Response object's Write method was called without using parentheses. In order to convert the site to ASP .NET, it was necessary for the ASP code to be converted from the following <% Response.Write "Thank You!" %>
to this: <% Response.Write("Thank You!") %>
|
|
8. In Visual Basic, all parameter arguments were, by default, passed by reference or ByRef. In Visual Basic .NET, this has changed so that all arguments are now passed by value or ByVal by default. If you still wish to have "ByRef" behavior, you must explicitly use the ByRef keyword in front of your parameters as follows: Sub MyByRefSub (ByRef Value) Value = 53; End Sub This is an area where we really need to be careful. When you are moving your code over to ASP.NET, double and triple checking each parameter used in your method calls to ensure that this change is what you really want.
|
|
9. After making these changes to the original ASP pages, the Web site should be up and running under ASP .NET. This part of the migration can be done in a very short period. To identify all of the places where these changes were needed, you can create a new Visual Basic Web application in the Visual Studio .NET IDE, rename the existing ASP pages using the .aspx extension, and added them to the project. Once the pages are in the IDE, Visual Studio .NET provides syntax highlighting and task list "to do" items, and compile-time errors became easy to track down.
|
|
10. The following VB Key words have become obsolete a. Replace Wend with End While b. Replace IsNull with IsDBNull c. Date function has become obsolete instead use DateTime class.
|
|
11. Array index are zero based instead of one based.
|
|
|
|
|
|
1. Disable session state when you are not using it. Not all applications or pages require per-user session state, and you should disable it for any that do not. To disable session state for a page, set the EnableSessionState attribute in the @ Page directive to false. For example, <%@ Page EnableSessionState="false" %>. Note: If a page requires access to session variables but will not create or modify them, set the EnableSessionState attribute in the @ Page directive to ReadOnly.
|
|
2. Avoid unnecessary round trips to the server. Typically, you need to initiate round trips to the server only when your application is retrieving or storing data. Most data manipulations can take place on the client between these round trips. For example, validating user input from HTML forms can often take place on the client before that data is submitted to the server. In general, if you do not need to relay information to the server to be stored in a database, you should not write code that causes a round trip.
|
|
3. Use Page.IsPostBack to avoid performing unnecessary processing on a round trip. The IsPostBack property can be used to conditionally execute code depending on whether the code is generated for the first time or is generated in response to a server control event. This can be useful particularly in the Page_Load event, which executes on every request.
|
|
4. Do not rely on exceptions in your code. Since exceptions cause performance to suffer significantly, you should never use them as a way to control normal program flow. If it is possible to detect in code a condition that would cause an exception, do so. Do not catch the exception itself before you handle that condition. ' Consider changing this... Try result = 100 / numCatch (e As Exception) result = 0End Try// ...to this.If Not (num = 0) result = 100 / numElse result = 0End If |
|
5. Be sure to disable debug mode. Always remember to disable debug mode before deploying a production application or conducting any performance measurements. If debug mode is enabled, the performance of your application can suffer a great deal. |
|
|
|
|
|
|
|
2. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/aspnetmigrissues.asp
|
|
3. http://msdn.microsoft.com/msdnmag/issues/01/09/migration/default.aspx
|
|
|
|
|
|
|