Language Changes

Several significant language changes must be considered when converting to ASP.NET. VBScript was replaced with Visual Basic .NET, and JScript was made into a real language capable of being used in the .NET architecture. Because changes made to these languages differ , they will be handled separately.

VBScript

Numerous changes will need to be made to current ASP code written in VBScript. Some of these changes are due to the move from VBScript to Visual Basic, and other changes are from VB changing as it moves to Visual Basic .NET.

Here are the main language related changes for Visual Basic .NET:

The default setting for the Option Explicit keyword is on .
Only indexed default object properties are supported.
The LET and SET statements are no longer supported.
Several underlying data types have been changed.
Parentheses must be used with method calls.
By default, arguments are passed by value rather than by reference.
Collections are 0-based instead of 1-based.
Structured exception handling should be used rather than the On Error Resume Next and On Error Goto methods of error handling.

`Option Explicit`

In ASP, the default value of the Option Explicit keyword is off . In ASP.NET, the default value of the Option Explicit keyword is on . This means that variables must be declared before they can be used. Every time a variable is used without being declared, a compiler error is generated. It is possible to turn this off by placing the following code at the beginning of each page:

 Option Explicit=off

Doing this, though, is not good programming practice because it can lead to errors that are hard to debug. Performance can also be adversely affected by not declaring variables before using them, because all undeclared variables are considered to be type Object and are declared globally to the page.

It is even better to use the Option Strict keyword. Using the Option Strict keyword forces you to explicitly type each variable. Following this practice can reduce runtime errors that result from assigning the wrong data to a variable. Explicitly typed variables increase performance by allowing the compiler to use an intrinsic data type. COM objects that are explicitly typed also receive a significant performance boost because they are early bound rather than late bound, which prevents costly calls to the object's IDispatch interface. Early binding allows the compiler to determine at compile time whether a COM object method exists and the number and type of arguments that can be passed to the method. Late binding requires that the existence of the method and the number and type of arguments be determined when the program is run. This determining of the method's existence and what kind of arguments it has can take more computer time than the actual execution of the method's code.

When using the Option Strict keyword, the following are disallowed and will result in compiler errors:

Narrowing conversions without an explicit cast operator.
Late binding by not explicitly typing COM objects.
Operations on type Object other than = , <> , TypeOf...Is , and Is .
Omitting the As clause in a declaration.

Indexed Default Object Properties

Although Visual Basic .NET still has default properties, the way they can be used has changed. Visual Basic .NET only allows indexed default properties. Indexed properties are properties that take arguments. This was done to eliminate confusion in specifying the name of an object with a non-indexed default value. Assuming that the objRs variable is defined as type Recordset , let's look at some examples of correct and incorrect use of default properties.

First, let's look at the correct use of default properties. In the following statement, no default property is used, so there is no problem:

 objRs.Fields.Item(1).Value = String1

Because the Item property in the previous statement is parameterized, it can also be used as follows :

 objRs.Fields(1).Value = String1

Now, let's look at some incorrect uses of default properties. The following statement is incorrect because the Fields property is not parameterized and needs to be specified:

 objRs(1).Value = String1

In the final statement, the Value property is not parameterized and needs to be specified:

 objRs.Fields(1) = String1

`LET` and `SET` Statements

Because only default properties with arguments are allowed in .NET, you no longer need to use special statements to indicate the assignment of an object rather than the assignment of the value of the default property. Therefore, LET and SET statements are no longer used. Objects must be assigned to one another directly, like this:

 Object1=Object2

If you use the LET or SET statements in your code, you must remove them.

Changed Data Types

Several changes were made to data types that are relevant to ASP-to-ASP.NET conversion. The biggest change is that the underlying data type in ASP was a Variant , whereas the underlying data type in ASP.NET is an Object . This can be a problem in certain situations because the data types in an Object are different from those in a Variant . Specifically, changes were made to the Date , Integer , and Long data types.

The Date data type in ASP is stored as a 4-byte Double . The Date data type in Visual Basic .NET uses the Common Language Runtime (CLR) DateType type, which is an 8-byte Integer . This can cause problems if you pass a Date value to a COM object as a Double . Additionally, casting a Date to a Double doesn't work anymore. If you need to use a Date object as a Double , you must use the ToDouble and FromOADate methods of the Date object.

In Visual Basic .NET, Integer values are now 32 bits long, and Long values are 64 bits long. You therefore need to pay special attention to the data type required when making calls to COM objects to ensure that you are passing or casting the values correctly.

Method Calls

In ASP, the use of parentheses on method calls of objects was optional. In ASP.Net, the use of parentheses is required.

The following example shows a valid ASP method call:

 Sub DoSomething()      Response.Write "Something was done"  End Sub  DoSomething

The same code would need to be rewritten for ASP.NET, as shown in the following example:

 Sub DoSomething()      Response.Write("Something was done")  End Sub  DoSomething()

Arguments

Another change to Visual Basic .NET is in the way arguments are passed in method calls. In ASP and VB6 the default was to pass arguments by reference, and if the argument was to be passed by value, the ByVal keyword was used. This has been changed. In Visual Basic .NET, all arguments are now passed by value as the default. If you want to have the variable passed by reference, you must explicitly declare your parameter to be passed by reference using the ByRef keyword, as shown in the following example:

 Sub MySubroutine(ByRef value)      value=100  End Sub

You should take care when converting your code to verify every subroutine and function to be sure they are declared properly. Many current functions might rely upon ByRef behavior and will need to have this explicitly defined with the ByRef keyword.

Collections and Arrays

Collections and arrays in Visual Basic .NET changed from being one-based to zero-based . This was done to make Visual Basic .NET meet the .NET standards for programming languages. If you iterate through collections and arrays using For...Each...In syntax, you will not have any problems. However, if you access elements by numeric position, you must be careful that you do it correctly.

Structured Exception Handling

Although VB still supports the On Error Resume Next and On Error Goto methods of error handling, moving to the new structured exception handling model using the Try , Catch , and Finally keywords is a more powerful and consistent method of handling your errors.

When moving your code to ASP.NET, you must consider not only the simplest and easiest way of moving your code, but also things such as modifications and maintenance of your code in the future. If you take the time to rewrite your error handling with structured exception handling, you can handle your errors consistently in both your old code and any new code that you will write. Handling errors consistently makes it easier to maintain and upgrade your code without undetected problems.

JScript

If you are migrating a JScript ASP application, you might want to consider converting it to a C# application. I make this recommendation because Visual Studio .NET provides minimal support for JScript ASP.NET applications. If you continue using JScript, you will not be able to use many of the code-generation features of Visual Studio .NET and will need to implement them by hand.

Unlike VBScript, JScript did not change much. Many new features were added, though, that you might want to take advantage of in your code. This section outlines some of the changes you will want to make to maximize performance and make your code more readable.

Use Strongly Typed Variables

Strongly typed variables are variables that are declared with a specific data type. The change that can help boost your performance the most is the capability to use strongly typed variables. In previous versions of JScript, variables were declared like this:

 var nValue;

Strongly typed variables are declared like this:

 var nValue:Integer;

Beyond a gain in performance, strongly typed variables make your code easier to read and less prone to errors. To enforce strongly typed variables, you might want to consider using the fast option directive. This can be done by placing the following line of code at the beginning of your JScript source:

 @set @option(fast)

Using this option enforces the following rules. To make your code work, you might need to modify it in other ways than by just strongly typing your variables.

All variables must be declared.
You cannot redefine or assign values to functions.
Predefined properties of built-in objects cannot be assigned to, deleted, or enumerated.
Expando properties are not allowed on built-in objects other than the Global object (global scope). Expando properties are arbitrary properties that can be added to an object.
Function calls must supply the correct number of arguments.
The arguments property is not available within function calls.

The fast option is enabled by default for all packages except the default package, where all legacy scripts reside.

String Object and String Data Type

One thing to be aware of is that the String data type is not the same as JScript's String object. The String data type is equivalent to the System.String data type in the .NET architecture. If you want your string variables to continue using the JScript String object, you must define them as type Object , as shown in the following example:

 var sValue : Object;  var sValue=new String("text");

All string literals are by default defined to be JScript String objects.

If you declare your variable with the String data type, it will have the methods and properties of the .NET System.String datatype. The following example shows a variable of the String data type being defined and used:

 var sValue : String:  sValue="text";

COM Objects

To get the most out of COM objects, you should have them early bound. If you define and use COM objects the same way that you did in previous versions of JScript, they will be late bound. Here is an example of a late bound COM object:

 var oRs:Object=new ActiveXObject("ADODB.Recordset");

Because JScript is not strongly supported in Visual Studio, you need to do the following steps to use COM objects as early bound objects:

Create a .NET wrapper This can be done by using the command line tlibimp myobject.dll /out:mylibrary.dll to create a .NET assembly named mylibrary.dll that can be imported into your code.
Copy to Library Folder You then need to copy the generated library file to your wwwroot \bin folder.
Import Assembly The .NET assembly that you created can be imported by adding the following two lines of code at the beginning of your source file:
```
 <%@ import namespace="MyLibrary" %>  <%@ assembly name="MyLibrary" %> 
```
Create Object The object can now be created as follows:
```
 var obj : MyObject = new MyObject; 
```

After following these steps, you can continue using your object as normal.

Variable Arguments

The way that JScript handles variable numbers of arguments has been changed. You can continue to use the old method by accessing the intrinsic arguments property of the function unless you use the fast option.

Variable numbers of arguments are now handled by an array of objects as the final argument in the function argument list.

Here is the method of accessing variable numbers of arguments in versions of JScript prior to JScript.NET:

 function myFunction(arg1)  {      if(myFunction.arguments.length>1)      {          //Process multiple arguments here      }      else      {          // Process a single argument here      }  }

Here is how variable numbers of arguments should be handled in JScript .NET:

 function myFunction(arg1:Integer,... args:Object[])  {      if(args.length>1)      {          //Process multiple arguments here      }      else      {          // Process a single argument here      }  }

In the first example, note that it is still possible to have a runtime error if no arguments were passed and you tried to access the first argument. In the second example, a strongly typed first parameter is used as the first argument. A compiler error is then generated if at least one argument is not passed to the function.

Rewrite Objects to Use Classes

If you have developed any JScript objects that use prototype functions, you probably should convert them to objects that use the new class syntax. This will greatly increase the readability of your code.

The following is an example of an old-style JScript object:

 function obj1Function1()  {      // Do something.  }  function myObject(arg1)  {      var nNumber=arg1;      var Function1=obj1Function1;  }

The following is an example of an object created using the class syntax:

 class myObject  {      var nNumber:Integer;      function Function1()      {          // Do something.      };  }

Using the class syntax is also much more powerful than the old function prototype method of creating objects because you can use inheritance. Proper use of inheritance can help reduce the amount of code you need to write to implement groups of related objects.