| 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: |
 |
| VBScript is gone and VB.NET (or C#
or JavaScript) is in. Even if you are familiar with
traditional VB, there are a number of changes you
will have to make to accommodate the differences
in VB.NET. |
 |
| 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: |
 |
| \WINNT\Microsoft.NET\Framework\v1.0.2204\xspisapi.dll
|
 |
| 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 arent 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: |
 |
| Sub MySub |
 |
| |
Val = Request.Form(Val)
%> <INPUT type=text <% |
 |
| End Sub |
 |
| 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
End Function
%> |
 |
| must be converted to |
 |
<script Language=VB
runat=Server>
Function Add(a, b)
Add = a + b
End Function </script> |
 |
| 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: |
 |
| In
ASP: |
 |
| 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 |
 |
| In
ASP.NET: |
 |
| 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 youre 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:
|
 |
Dim s
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 isnt going to work. Youd 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#, youre going to have some extra syntax
work to do of course. Heres 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 thats 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: |
 |
| C#: ServerVariables[HTTP_REFERRER] |
 |
| VB: ServerVariables(HTTP_REFERRER) |
 |
| 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 youre used to writing things like Server.HTMLEncode()
youll 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 youve been
using error-free for years. |
 |
| Final
Thoughts |
 |
| Youll notice that your development
speed slows down quite a bit under ASP.NET unless
youre 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. |
 |
  |