Frequently Encountered Bugs

I l @ ve RuBoard

Frequently Encountered Bugs

If you're a veteran VBScript/ASP developer, here are a few things to watch out for as you debug your ASP.NET pages. These are the kinds of mistakes you'll probably find yourself making as you transition from ASP to ASP.NET programming.

Runat="Server"

Script blocks and controls all need to be marked with the attribute RUNAT="Server" if you want them to be processed by ASP.NET. It's especially common to forget this on FORM tags. Remember, if you want to take advantage of ASP.NET's form-handling capabilities, the form itself must have a RUNAT="Server" attribute. Further, you can only have one form per page that is configured this way. If you think you need more than one form, you probably don't. Consider using more than one button-click event handler instead, but only one form. You will find that nearly any page you design can be built successfully using just one server-side FORM tag. Also note that, if you omit the FORM entirely, your web controls will fail, which is another common mistake to watch out for.

Type Mismatches

Type mismatches are rarely a problem in the weakly typed VBScript environment, but you may find them to be a common problem as you move to a strongly typed VB or C# programming language. Get to know the typecasting syntax of your language of choice, and make use of the framework documentation to ensure that you are using parameters and return types that are correct. Although somewhat common, these bugs are usually pretty easy to find, thanks to the fact that the ASP.NET compiler is pretty good about giving useful error information for these errors.

VB/VBScript Syntax

If you've primarily used VBScript (and perhaps VB6 or earlier) for your ASP development, going to VB.NET may result in some other common mistakes apart from type mismatches. In fact, quite a number of things have changed between VBScript/VB6 and VB.NET. Here are a few tips to remember for your ASP.NET development ”of course, this is far from an exhaustive list of the differences between VBScript and VB.NET. You will find additional information about VB.NET in Appendix C.

Parameters Are Passed ByVal by Default

In previous versions of Visual Basic, parameters were passed ByRef by default. Starting with VB.NET, this has changed, and the default is now ByVal . This may result in unexpected results if legacy functions are migrated to .NET without taking this into account. I recommend that you always explicitly specify ByVal or ByRef for each parameter in your functions so that changes to the default behavior do not adversely affect your code as it is ported from one platform or version to another.

Calling Procedures

In previous versions of Visual Basic, there were two ways to call procedures (Subs). You could use the Call keyword and enclose the arguments in parentheses, as in the following example:

 Call mySub({ parameters} ) 

Or you could simply refer to the procedure by name and list any parameters after it separated by commas (without parentheses), as in the following example:

 mySub { parameters} 

With VB.NET, this second option is no longer supported. Calls to procedures and calls to functions share the same syntax, in that both are required to list any parameters inside parentheses. This is typically how other languages behave, so personally I think this is a welcome change. However, if you are in the habit of listing your parameters after a procedure call with no parentheses, you might not appreciate this change, because your code will fail to compile. The Call keyword can still be used optionally in VB.NET, so a procedure call looks like this:

 { Call}  mySub ({ parameters} ) 

Date and Time

The VB/VBScript functions Date() and Time() have been replaced in VB.NET with Today() and TimeOfDay() . Trying to use the old function names will result in compile errors.

Dim Syntax

It is unlikely that the Dim syntax will cause any bugs for most developers, because the change tends to make code that behaves more intuitively. However, I think it is worth noting here, because it is an important change from VB6 to VB.NET (it's not really an issue in VBScript, where everything is Variant ). In previous versions of VB, the following statement would result in the creation of three variables : Variant x , Variant y , and Integer z :

 Dim x, y, z As Integer 

To create three integers with one Dim statement, each variable's type must follow each and every variable. With VB.NET, this has been changed so that the preceding line would result in the creation of three integers. This is more intuitive and makes for code that is easier to read. However, under VB.NET, you can no longer Dim variables of different types on one line. All variables in a single Dim statement must share the same type.

Wend Is Now End While

While loops in VB.NET are closed with an End While , not with the keyword Wend as in previous versions. If you are writing functions that need to coexist in both VB.NET and earlier versions, consider using the Do While...Loop syntax, which provides the same functionality and operates the same in both VB.NET and earlier versions (and also supports the Exit Do short circuit syntax to exit the loop). Using the familiar While...Wend syntax will cause you problems in VB.NET.

I l @ ve RuBoard