by December 5, 2002 0 comments

Visual Studio.NET not only helps the existing VB6 developer community to migrate easily to .NET, but also helps them to accomplish development scenarios that weren’t possible previously, like implementing threading-in applications. Let’s see how to graduate to VB.NET from VB, the differences between the two development tools and the things to be kept in mind during migration. 

Upgrade Wizard
Typically, when you will open a VB6 project in the VS.NET IDE, the Upgrade Wizard will be automatically invoked and will help your application migrate to equivalent VB.NET code. The wizard is good at its work, but depending upon the complexity of the project being upgraded, it will take its time and the upgrade may or may not be 100%. Here’s a typical scenario of using late-binding in your application, where the Upgrade Wizard will mark it with an error:

Dim myObj as Object
Set myObj = Me.cmdOK
myObj.Caption = “&Cancel”

This code is just fine for VB6. However, when the Upgrade Wizard encounters it, it isn’t able to ascertain what type the object variable myObj references. Thus, though typically all references of the Caption property are upgraded to the Text property, in this particular case the change will not occur and the code will be marked with an error. So, it is imperative that prior to upgrade, you should ensure that all variables are of a specific type than of the Object type. 

Unlike VB6, which allows you to use an Object variable to refer to an interface and then access the relevant properties and methods of that interface, VB.NET, doesn’t allow you to do that. Hence, you will need to change such code also.

Also, if your application is referencing other COM components, there are chances that if relevant information for them isn’t available, the upgrade may not be successful. The following section discusses this.

COM Components 
Typically, in a pure .NET solution, you will not find a need to use COM components. One reason for this is that the components execute outside the managed .NET environment and the second is that calls to them go via interoperability layers, which can slow down the application. However, there will be scenarios when you need to leverage on the existing code base, maybe because the .NET version of the component isn’t out yet. 

To handle such scenarios, we create the RCW (Runtime Callable Wrapper) of the component in question. Let’s suppose that you wish to continue using ADO in your VB.NET project, and not use ADO.NET. This will require you to add a reference to the ADO DLL like you used to do in VB6. Only, things are different. Internally, when you add a reference to the ADO DLL (a COM component), the VS.NET IDE uses the TLBIMP.EXE utility to create the RCW for the ADO DLL. The RCW is implemented as a .NET DLL assembly, which acts as if it’s the ADO DLL, to your VB.NET application. However, when calls come to it, the RCW internally, via marshalling, make the calls against the COM component, gets the work done, and then returns the results in the expected format to your application. Thus, with the RCW, you have to yourself all the ADO classes that you need to work with, just like with VB6 . The only issue is of performance, since the calls go via the
interoperability layers.

Data types
Working with the correct data-type is very important since the nature of data types (value and reference types), and their size (eg. VB6 long has equivalent size to the VB.NET Integer) have changed considerably from VB6 to VB.NET. Here are few tips that must be kept in mind:

l Everything is an Object in .NET. While in VB6 Variant was conveniently used to assign it any primitive data type, in VB.NET, the Object data type combines the power of both the VB6 Object and Variant data types and is the default data type of VB.NET. During a projects migration, all references to Variant are updated to VB.NET Object references.

l Integral data types have their sizes changed. A VB6 Long (32bits) is equivalent to a VB.NET Integer (32bits), but smaller than the VB.NET Long (64 bits). You should know the .NET Data types well, before the migration. All data types in VB.NET map to one of the various data types of .NET, as defined by the Common Type System (CTS). Make appropriate changes in your code so that relevant .NET data types come up after migration.

l Unlike VB6 which stored Date as a Double value, VB.NET has a new 8-byte Date data type for storing the date. The ToOADate and FromOADate functions are used to convert between the old and the new types.

l VB.NET has a new 32bit Boolean data type which stores the value of True as 1, in contrast to VB6 which used -1 to indicate the same. Thus, any applicable hard coded True/False check conditions in your code must be updated.

l Arrays are now zero-based. Thus,Dim x(10) as integer
is an Integer array, subscripted from 0 to 9, unlike VB6 where this would contain 11 elements.

l Fixed length strings are no longer supported in
VB.NET. Incase you need to create the .NET equivalent of the same, use the StringBuilder class.

Update programming skills
Now that we have gone through the changes in the data types, let’s have a look at the modifications to programming in
VB.NET. Instead of using IsMissing in VB6 to check if the optional parameter has been specified or not, VB.NET mandates that the declaration of a method, containing optional parameters, contain a default value for the parameter

function SetName(ByVal sName as String, Optional ByVal sGender as String = “M”)

Thus, the optional parameter’s default value is used to check if it was passed or not. Return statement is now used to return control to the calling function and also to return any values to the caller. This is in contrast to using Exit Function, or setting the value to be returned to the caller, to the function’s name.

Function overloading is completely supported in the true sense of it, by variating the function signature, as is done in any other OO language.

COM Interoperability allows you to make your VB.NET application invoke the functionality of a COM component, using
RCW, and the COM Clients can invoke the functionality of your VB.NET component using COM Callable Wrapper

Error handling had undergone a complete change with the introduction of structured exception handling
(SEH) by the use of Try/Catch/finally blocks. This allows exceptions (i.e. error conditions) to be reported and hence, thrown, across function call boundaries, up the caller’s stack. This is the preferred mechanism of handling and throwing errors, although the On Error …. Concept of handling errors is still supported. When using SHE in your VB.NET components, the exception can be thrown which can be handled by the client using your library, may that client be written in C#. This cross handling of exceptions will not be possible if you use On Error ….

Interfaces are declared using the Interface keyword and implemented using the Implements keyword. Short circuiting is now supported in
VB.NET. Bitwise operations are supported using the new BitOr, BitAnd and BitXor operators.

Upgrade data access
Data access has changed considerably with VB.NET. VB6 promoted the use of ADO object model. VB.NET supports a new data access methodology,
ADO.NET. Except for the name, there’s nothing common between the two.

l While ADO was a totally connection oriented approach to work with data, ADO.NET is absolutely disconnected in nature.
The philosophy is to connect to the data source, get the data, disconnect, modify the data, reconnect and update.

l Recordset is replaced by a more powerful entity which goes by the name of Dataset. While Recordset was simply a consolidation of rows, typically from a single table unless JOINs were used, as result of a query against the database, the Dataset is a container of one or more tables from the database, which contains rows.

l A Dataset contains not only tables from the data base, but also contains the relations between tables, constraints, views, amongst other things.

l Unlike ADO which allowed for a variety of locking types, ADO.NET supports optimistic concurrency handling, i.e., optimistic locking only.

l The only connected way to work with a Data source is to use the DataReader object, which also implements the server side cursor.

l ADO.NET has specialized classes for working with SQL server, ensuring faster and more efficient access to the same. Additionally, it has complete support for working with OLE-DB and ODBC drivers.

There have also been additions to VB.NET:
l VB.NET now supports designing Windows Services: NT Services which run in the background to provide typical server side functionality. Prior to
VB.NET, this was the domain of VC++.

l You can now design multi-threaded applications in
VB.NET. Spawn threads? control their priorities? all that is possible. Coupled with the fact that you can create Windows Services as well, you are poised to design scalable server side applications.

l What if you don’t want to spawn threads yourself but still want to use them? VB.NET allows you to use the .NET Thread pool, which is a collection of threads executed and managed by the .NET Runtime. You can use this thread pool to create multithreaded applications that are scalable, without the headache of managing each thread.

l Finally, you can create business-tier objects for the COM+ environment that support object pooling! VB6 didn’t support the right object model and hence, COM+ components created in VB6 couldn’t take advantage of object pooling. But not so anymore. ServicedComponents allow you to create components that can take advantage of .NET as well as COM+ services like object pooling, queued components,
JITA, and more.

VB.NET has thus evolved into a more productive development tool that allows you all the flexibility as in any other language. 

Kumar Gaurav Khanna a Microsoft .NET MVP runs

No Comments so far

Jump into a conversation

No Comments Yet!

You can be the one to start a conversation.