Lauren is a partner in Spin Solutions, LLC. She can be contacted at [email protected].
If you think that the next iteration of Microsoft's Visual Basic is somehow related to its predecessor, Visual Basic 6.0, in any way other than in name, think again. Visual Basic.NET, better known as VB.NET, is a completely reengineered version of the language with dramatic changes in the areas of deployment, data typing, inheritance, and data access.
Why the change? After all, Visual Basic 6.0 is used by millions of programmers because of its accessible syntax and rapid development capabilities. Well, Visual Basic 6.0, along with other Microsoft tools bundled into the first release of Visual Studio, was not engineered with the Web in mind. Because Microsoft was so late in adopting Internet technology and the concept of distributed, stateless applications, it had to retrofit its existing toolset, rather than design new tools for the new development environment. As a result, Visual Studio tools fall painfully short in producing web-based applications that are easy to develop, deploy, and debug. Instead, for three years, developers have used a variety of tricks and techniques to produce distributed applications. The resulting applications are difficult to produce and not optimized for web-based production environments.
VB.NET changes all this. The toolset has been completely reengineered from the ground up to make it easy to develop web-based and client/server applications in a distributed, disconnected world. The productivity and technical gains you enjoy with VB.NET are more than worth the time and effort you'll spend learning the new tool.
As Table 1 shows, the differences between Visual Basic 6.0 and VB.NET can be categorized into two groups:
- Technical changes that improve the performance of applications and drive the syntax and programming-practice changes.
- Syntax changes or programming-practice differences that require you to change the way you write code.
Technical Changes
The technical changes included in VB.NET are the driving force behind the syntax and programming-practice changes. The syntax and programming-practice changes in VB.NET are required because of the technical objectives Microsoft is working toward in its new release of VB.
To bring VB in line technically with C++ and C#, Microsoft developed the Common Language Runtime (CLR), which serves as the foundation of all three languages and is at the heart of all applications written in any of the three languages. VB can no longer be considered a pseudocode generator. The CLR makes it a true object-oriented language and puts it on the exact same footing as C++ and C#. An application generated by VB.NET is technically indistinguishable from one generated in C++ or C# because of the CLR.
Syntax Changes
While the technical changes to VB.NET are extremely important (and much applauded), they are not as important to the immediate adoption of VB.NET as the syntax and programming-practice changes. I'll examine these changes in more detail because they affect the viability of converting Visual Basic 6.0 applications to VB.NET and help assess the learning curve required to start using VB.NET.
Microsoft included an Upgrade Wizard in the Beta 2 version of the .NET suite of tools to help migrate existing VB 6.0 applications to VB.NET. When appropriate, I indicate the effectiveness of the Upgrade Wizard to assess and fix some of the inconsistencies between VB 6.0 and VB.NET.
Data Type Changes
Say goodbye to the Variant, Short, and Long data types as you know them. VB.NET has combined the Object and Variant data types into the single Object data type. Variant was the VB 6.0 default data type assigned to all variables not specifically typed. In addition, Visual Basic assigns variables beyond the first one defined on the same line as variants. Consequently, the line:
Dim ipCount, ipNumber as Integer</p>
declares the ipCount variable as an integer and the ipNumber variable as a variant. The Integer data type is now Short (16-bit whole number) and the data type that was known as Long is now Integer (32-bit whole number). Long is now a 64-bit whole number. The Upgrade Wizard does a good job of replacing all instances of the Variant, Integer, and Long data types.
Variable Scope Declaration Issues
VB 6.0 grants all variables declared in a procedure "full procedure scope." That means that once a variable is declared, it can be accessed anywhere in the procedure. VB.NET reduces the scope of variables defined inside of blocks to the block they are declared in.
In VB.NET, for instance, Example 1 produces an error because the variable goes out of scope once the block (defined by a beginning Do, For, or If statement and ending with a Loop, Next, or End If statement) has terminated. Once the For...Next block terminates with the Next statement, the variable j is out of scope because it was declared inside the block. You can avoid this issue by declaring all variables at the beginning of a procedure regardless of where they are used.
The Upgrade Wizard will include any suspicious scope declarations in its final report, but will not fix them automatically.
Data Access
Visual Basic 6.0 supported ADO, RDO, and DAO for data-access purposes. VB.NET recommends an enhanced version of ADO, ADO.NET, which has improved namespaces that make working with disconnected data sets more efficient.
VB.NET supports ADO, DAO, and RDO (with some minor modifications) with one major exception — VB.NET does not support DAO and RDO data binding to controls, data controls, or RDO User Connection.
If you've used DAO or RDO in conjunction with data binding controls in VB 6.0 applications, don't upgrade to VB.NET unless you want to spend an inordinate amount of time rewriting the code that binds data to controls. It is virtually impossible for the Upgrade Wizard to interpret your existing data-access code and convert it to ADO.NET- or even VB.NET-acceptable language. The unsupported code has to be changed manually.
Binding
Early binding is the practice of declaring a variable and assigning it to an instance of a class before the application is compiled. Doing so instantiates the object and stores it in memory from the time when the application is run until you use it. For instance, Example 2(a) uses early binding to declare the variable rsRecordset as an ADODB.Recordset.
Late binding, on the other hand, is the practice of declaring a variable as an object and then assigning it to an instance of a class at run time. Late binding is good to use when you think a module might not be used frequently and you don't want to load an instance of a class in memory unnecessarily. Example 2(b) uses late binding to declare a variable and bind it to an instance of the ADODB class when it happens upon it in the code.
The Upgrade Wizard can convert early-bound objects much easier than late-bound objects because it can convert properties and methods of strongly typed variables, but not late-bound objects.
ByVal and ByRef Parameters
By default, variables passed into a VB 6.0 function or subroutine not specifically declared as ByRef or ByVal were assigned automatically based on their type of parameter. All intrinsic data types such as integers, strings, Booleans, and variants were defined ByRef. Object references and user-defined data types were assigned ByVal.
VB.NET defaults all parameters to ByVal unless they are explicitly declared otherwise. This can cause serious problems in applications if you have an intrinsic data type parameter (a string, for instance) that you want the function to alter. If you do not specifically assign the variable ByRef, VB.NET treats the parameter as ByVal.
In VB 6.0, Example 3(a) changes the value of the string passed in because the parameter shString is automatically passed in ByRef. In VB.NET, Example 3(a) leaves the string unchanged because the parameter would be passed in ByVal by default. To change the string inside the procedure, the parameter shString has to be explicitly declared ByRef as in Example 3(b).
Default Properties
Visual Basic programmers have enjoyed default properties as a syntax shortcut for years. For instance, the default property for the Textbox component is Text. So, assuming Text1 is the name of a text box on a form, Example 4(a) represents the exact same functionality.
VB.NET no longer supports default properties for parameterless objects. However, VB.NET does support default properties for objects that require a parameter. For instance, without using the default properties, Example 4(b) would be written like Example 4(c).
Example 4(b) has two default properties, Fields and Value. The Fields property requires the name of the field as a parameter. The Value property does not require a parameter; thus in VB.NET, it must be explicitly stated. Example 4(d) would be interpreted correctly in VB.NET.
The Upgrade Wizard can determine the default property for most, but not all, objects. In addition to the potential incompatibilities with VB.NET, it is good programming practice to abandon the use of default properties altogether and explicitly state the property name for the purposes of code clarity and readability.
The Double Data Type
It has also been a common practice for VB 6.0 developers to use the Double data type to store dates. Internally, VB 6.0 converted and stored dates as doubles. However, VB.NET does not. Instead, it uses the Date data type to store dates.
The Upgrade Wizard has a difficult time assessing the intent of a double. Consider this code:
Dim dpDate as Double<br>
DpDate = opRecordset("CancellationDate")</p>
As you can imagine, it is impossible for the Upgrade Wizard to determine that the CancellationDate field is truly a Date data type and alter the code appropriately. Instead, the Wizard flags any use of the Double data type and warns you that if you're using it to store a date, you should change the data type to Date.
Arrays
One of the language-friendly anomalies of Visual Basic 6.0 and its predecessors was the ability to create arrays with lower and upper bounds. That feature has been abolished to ensure interoperability with the other languages in the .NET framework.
VB.NET has a workaround built-in to handle nonzero-based arrays, but it is slow and cumbersome. Consequently, it is highly recommended that you redefine all of your arrays to be zero-based to take advantage of the much faster intrinsic array class.
For instance, the VB 6.0 code in Example 5(a) creates an array that starts at 3. In addition, the array a has 10 integers. To use the integers in the array, you could use Example 5(b) to sum the first, second, and third elements of the array. The new statement in VB.NET requires the array to be zero-based and would only have nine integers; see Example 5(c). The same code to sum the first three elements would look like Example 5(d).
ReDim is a popular command in VB 6.0 to reassign a variant as an array later in the code. VB.NET only lets you ReDim a variable that has already been declared as an object. You cannot ReDim a variable that has not yet been defined as you could in VB 6.0.
The Upgrade Wizard will flag the sections of your code that use nonzero-based arrays, but cannot convert them automatically.
True, False, and Constants
Much to the dismay of many VB developers, Visual Basic 6.0 broke with other language-coding norms and assigned -1 to the Boolean value of True. VB.NET fixes this anomaly and instead considers a Boolean value of True to be equal to 1. That could introduce some problems in your upgraded code if you test for a particular value instead of testing for True or False in your if statements. For instance, Example 6(a) would work if you were testing the Boolean value bpCheck for True in Visual Basic 6.0. In VB.NET, the same code would be written like Example 6(b). Either way, you could eliminate the discrepancy altogether by using the reserved word True instead of the numerical representation for True; see Example 6(c).
Similarly, use constants instead of a numerical representation of a parameter. For instance, the ADODB object has several methods that require you to pass in parameters that are defined as constants. Examples 6(d) and 6(e) do the exact same thing, but the first uses a constant instead of its numerical representation.
Using a constant instead of the numerical equivalent ensures that your application will be compatible with future releases of the object.
The Upgrade Wizard cannot detect the meaning of code that does not use the reserved words True and False when comparing Boolean values. It will, however, flag the code in its final report to let you know there could be a problem and you should review it.
Obsolete Syntax
In the interest of backward compatibility, recent releases of Visual Basic have contained old syntax that represented archaic programming techniques. The reserved words in Table 2 have been removed from VB.NET.
Conclusion
VB.NET is a new programming language, and Microsoft is betting the Visual Basic developer community will adopt it because it bears the same name as its enormously popular predecessor. While the syntax and programming-practice changes may take some time to master, the time investment is far outweighed by the advantages of VB.NET. Microsoft made the decision and invested the resources to reengineer VB from the ground up. The result is a technically sound toolset that couples the rapid development capabilities of VB 6.0 with the technical prowess of C++.
DDJ
