Porting ASP to ASP.NET
Porting your ASP project to .NET can range in difficulty from very easy to very involved, depending on the scope and coding style of the existing site.
Porting existing ASP projects into ASP.NET ones is sure to be a common task for some time to come. ASP.NET provides a rich framework of support for writing much better organized and robust web applications. In this article I’m not going to focus on the new features of ASP.NET but instead am going to recount some of the issues in simply making an ASP Web Application work under ASP.NET
In some cases the port can be very easy. The changes you will have to make are generally due to 2 reasons:
ASP.NET pages are compiled now in much the same way as JSP (Java Server Pages). This is really good news in that it promotes ASP.NET to a much more powerful programming environment. But this power comes with some added syntax changes and rules.
All in all, the benefits far outweigh the initial pain of porting over from ASP. Microsoft seems to have done a great job in making the port as painless as possible yet still breaking the shackles of ASPs limitations. Here is an ongoing list of issues to address in porting an ASP project to ASP.NET.
Top Ten List
1. Change .asp extensions to .aspx
This is the easy part. If you had IIS installed before you installed the .NET framework, then you don’t have to worry about this issue since IIS should be correctly configured for ASP.NET file extensions. If not, you will have to wire it up yourself.
On a sample machine, the following extensions were mapped to the xspisapi.dll located in:
For Beta 1, the list of extensions mapped to this dll are:
.asax , .ascx , .ashx, .aspx, .axd , .disco, .rem, .soap, .web
Some of these extensions are used for Web services and some are used only by VisualStudio.NET. If you aren't using VS.NET or web services you might get away with only mapping .aspx and ascx to start with.
2. Remove in-line ASP delimiters from subroutines and functions
This is possibly the most painful part of the port, depending on your coding style. Basically, you cant do the following in ASP.NET:
Val = Request.Form(Val)
Instead you must use Response.Write() to output the raw html. The conversion can be quite a chore if you have relied heavily on Subs to write a lot of html and ASP interspersed.
There's another reason the above example won't work. Look at the next tip:
3. All function calls must be in script tags not just ASP delimiters
For example, the following
Function Add(a, b)
Add = a + b
must be converted to
<script Language=VB runat=Server>
Function Add(a, b)
Add = a + b
4. Set is gone
You no longer use the Set keyword to assign objects. Assignment of objects is not syntactically different from non-object assignment under ASP.NET.
Set myObj = someObj 'NO MyObj = someObj 'YES
5. Wend is gone
If you were using the While/Wend pair this must be changed to While/End.
6. No more continued comments You cant do the following anymore
This is my comment to be & _ continued on this line
7. All arrays are now zero-based by default
Note: This issue may be reversed in VB.NET Beta 2. C# arrays will still be zero-based.
This is to allow interoperability with other .NET languages. So when porting to .NET all arrays must be zero-based and the accompanying DIM statements must contain the number of elements (not the upper bound). For example:
DIM MyArray(20) As String
Means an array with upper bound of 21 elements with subscripts from 0 to 20. If Option Base 1 is used the meaning of the above statement is: An array of 20 elements having subscripts 1 to 20 DIM MyArray(1 to 20) As String
Is an alternate syntax for using Option Base 1
DIM MyArray(20) As String
Means an array of 20 elements having subscripts 0 to 19
8. Syntax for calling subroutines has changed
With traditional VBScript and ASP you either used the Call keyword and parenthesis around the parameters or you omitted the Call keyword and used parenthesis. With ASP.NET the parentheses are always required. The Call keyword is optional.
9. True = 1 NOT True = -1
Note: This issue may be reversed in VB.NET Beta 2. Other .NET languages (such as C#) will still evaluate True as 1.
This might be a problem if you're using the value True for some numeric purpose.
10. Implicit conversions are turned off by default Unless you specify the new Option Strict off statement then ASP.NET wont be nearly as friendly about converting your data types for you. For example, if you have a String variable that you just happen to know (assume?) contains a numeric value in String form, you can do math with it under ASP:
s = "150"
s = s + 6
VBScript implicitly converts s to a VAL to do the math then casts back to a String (CStr()) to perform the assignment.
With ASP.NET and the default Option Strict ON this isn't going to work. You would have to do something like the following:
Dim s AS String
S = 150
S = CStr(CLng(s) + 6)
Again, this change is to allow interoperability with other .NET languages.
Note that some casts are allowable using Option Strict. These are casts where there will be no loss of precision such as assigning an Integer to a Double. The other way around wont work since not all Doubles will fit into an Integer.
Porting to VBScript to C# If you want to port from your ASP code written in VBScript to C#, you're going to have some extra syntax work to do of course. Here's a short list of VBScript to C# porting issues:
1 Use a Page directive Just like VBScript is the default language for ASP, VB.NET is the default for ASP.NET. This means to write ASP.NET pages in C# you have to specify C# as the language at the top of each page using the Page directive.
<%@ Page language=c# %>
2 Watch those include files Although you can mix and match languages within your ASP.NET application, you cant mix them on the same page (and there can be only a single Page directive per ASP.NET page). Since including a file actually inserts its contents into a page, you can only include a file on a page that is written in the same language. Of course, while server-side includes still work fine under ASP.NET their use is somewhat discouraged since there are better ways to achieve reuse.
3 Subtle syntax differences can affect collections and arrays Collections such as ServerVariables and Session are there but under C# have to be accessed using square brackets rather than parentheses:
4 Watch that case sensitivity! You may have adopted a case convention for spelling some of the ASP method names. It may seem obvious, but if you're used to writing things like Server.HTMLEncode() you'll have to use exact case to get Server.HtmlEncode(). This is a good place to start if you get a method name not found error on the intrinsics you have been using error-free for years.
You'll notice that your development speed slows down quite a bit under ASP.NET unless you're fortunate enough to have a fast machine. Waiting for pages to compile on first access definitely slows development progress. There are promises of compile at install options in the future to at least save your users from feeling the pain of compilation.