Common Migration Problems
In this section, we’ll examine some of the problems that can derail .NET migration.
If you can find these problems in your own Visual Basic 6 applications, it
may be a good idea to fix them within that environment before migrating the
project-or call off the migration process altogether.
TIP If you’re still developing projects in Visual Basic 6, the information in this section will
help you make choices that will facilitate migration in the future.
Arrays can thwart any attempt at migration. Visual Basic .NET’s new insistence
that every array have a lower boundary of zero can cause all sorts of trouble. In
our original VB6OrderMaker project, array indexes are chosen with specific
meanings. For example, the elements 1 and greater are used to contain the
items in an order. Element 0 contains a combined line with price totals, and
negative array indexes are used to contain licensing information for the ordered
items. Even though these specific array indexes are stored in variables instead of
being hard-coded, updating them to comply with the zero-boundary requirement
would not be easy, and would requires hours of modification and retesting.
Some early Microsoft documents promised that the Upgrade Wizard would
create special array classes that will mimic normal arrays and allow any lower
boundary that you need. This flexibility never materialized in the beta or release
versions, and it’s uncertain whether or not the new array classes would help at
all, or just complicate life even more.
However, it’s fairly easy to create a Visual Basic 6 program that won’t suffer
from this array problem. The best choice is not to use zero-bounded arrays at
all, but to move straight to collections or other custom classes. In our
VB6OrderMaker application, the Visual Basic 6 code would be clearer and more
elegant if orders were stored in an Order class that contained a collection of
ordered items as a property (for example, Order.Items), and any other required
license-specific properties. This class could also contain built- in methods for
retrieving the total cost of all ordered items, and for converting prices to different
currencies. The Order class approach would improve encapsulation, and
would result in a data structure that doesn’t depend on miscellaneous conversion
and helper functions in other modules of the program.
Variants are a special Visual Basic 6 data type that can store different types of
information, including strings or numbers. A variant converts itself automatically
according to how you try to use it. Historically, this automatic conversion
led to a variety of annoyances, although it was useful in some situations.
In Visual Basic .NET, variants aren’t supported, but the System.Object type
provides the same flexibility. If Option Strict is disabled for your application (as
it is by default when you are migrating a project), you can use the generic object
type in almost the exact same way as you would variants, with the same automatic
conversion feature. If Option Strict is enabled, you need to convert object
types manually when performing operations with them. This is explained in
Chapter 7 of The Book of VB .NET, but a quick review is helpful:
Dim x As Object, y As Object, z As Object x = 1 y = 2 z = x + y ' Will only work in Option Strict is off. z = CType(x, Integer) + CType(y, Integer) ' Always works without a hitch.
The Upgrade Wizard will convert all variants into generic objects. After a
typical migration, you may find yourself with many more generic objects than
you expected. The problem is that even though variants are rarely used deliberately
in VB 6 code, variables could be inadvertently defined without data types,
as shown here:
' VB 6 code. Dim intA, intB As Integer ' intB is an Interger, but intA will be a variant.
This oversight, which occurs most often when simple counters and other
unimportant temporary variables are defined, causes Visual Basic 6 to use its
default data type, which is the variant. During the migration of the VB6Order-
Maker program into .NET format, many unspecified counter variables ended up
as objects. The Upgrade Wizard flagged every subsequent line of code that performs
any operations with these variables, indicating that it can’t determine the
default properties for those objects:
Dim intA As Integer, intB As Object intA = 0
' UPGRADE_WARNING: Couldn't resolve default property of object intB. ' Click for more: ms-help://MS.MSDNVS/vbcon/html/vbup1037.htm intB = 0
This minor issue isn’t a problem-in fact, this portion of the code will still
work perfectly. However, this idiosyncrasy led to a large number of additional
warnings in the VB6OrderMaker upgrade report.
Why is the Upgrade Wizard so aggressive in flagging the unstructured use of an
object? In VB6OrderMaker, these objects really represent simple value types,
and the default value is automatically available as long as Option Strict is Off.
However, this type of operation could create a problem in other circumstances.
In .NET, standard default properties aren’t supported, and attempts to use
an object’s default property will fail. Usually, the Upgrade Wizard will add the
necessary information to qualify a default property (for example, change
txtBox = “Text” to txtBox.Text = “Text”). However, when you have a mysterious
late-bound type that’s defined only as an object, this trick fails. For example,
if x, y, and z were real objects with numerous properties (such as x.Value),
the statement z = x + y wouldn’t work. Visual Basic .NET would have no way
of knowing what properties to use for this calculation.
The solution to this problem is simple. When programming in Visual
Basic 6, be careful to always define data types. Also, don’t use late-bound
objects. Not only are they slower, because VB has to inspect them before they
are used, but they may lead to migration headaches.
In Visual Basic 6, you could use the Load statement to create a form without
' VB 6 code. Load frmMain
In Visual Basic .NET you can accomplish the same sort of thing by creating
an instance of your form class, but not displaying it.
Dim frm As New frmMain()
Both of these techniques allow you to pre-configure the form and its controls
before displaying the form. In VB6OrderMaker, Load statements are used
extensively to provide Wizards that automatically load other forms, use their
objects and procedures to calculate totals and create order items, and then
unload them. This approach is well organized, but not nearly as efficient or easy
to use as a real class- based design. It also leads to migration errors, because the
Load statement is not automatically upgraded.
There is at least one easy way to replace the Load statement in a migrated
This code initializes the form and makes it available through the shared
The Upgrade Wizard is not able to update printing code. During the migration
of VB6OrderMaker, the code used to select the printer, configure device settings,
and output an order was flagged with error messages. The only way to
resolve such problems is to rewrite the code for the new PrintDocument object
in the .NET class library. If you’ve spent hours generating custom formatted output
in your original application, you will not enjoy the migration process.
Code that interacts with the Windows clipboard will also fail to work after a
migration. Once again, the Upgrade Wizard leaves the hard work to you, and you
need to rewrite the code with the .NET equivalent. In VB6OrderMaker, the clipboard
was used to transfer information into the RichText control for a preview.
Clearly, a better approach is to use .NET’s new PrintPreview control. Unfortunately,
there’s no migration path between the two. If you are still working on a
VB 6 project, you have no easy way to use print preview features similar to those
available in VB .NET, and you will have to resort to third-party components or
nontraditional approaches, such as those found in VB6OrderMaker. In .NET,
however, there’s really no reason not to use the bundled PrintPreview control.
The HelpContextID property is not supported in Visual Basic .NET. If you want
to create context-sensitive help, you’ll need to use the HelpProvider control,
which was discussed in Chapter 4 of The Book of VB .NET. This control provides a number of minor
enhancements, but once again, the Upgrade Wizard won’t help you make the
coding changes. Any program-VB6OrderMaker, for instance-that makes significant
use of context-sensitive help will need at least some rewriting.
In Visual Basic .NET, you can’t use the same menu component for an application
(pull-down) menu and a context menu. In Visual Basic 6, you had to create
a pull-down menu before you could use it in a context menu. Microsoft schizophrenia
The VB 6 code used to display a context menu looked like this:
' VB 6 code. Private Sub Form_MouseDown(Button As Integer, Shift As Integer, X As Single, _ Y As Single) If Button = 2 Then PopupMenu mnuOrderOptions End If End Sub
When importing a project that uses context menus, the Upgrade Wizard
leaves the PopUpMenu command in its original state, and flags it as an error.
Before you can make it work, you have to create a new ContextMenu object.
Then, you have to copy the ordinary menu information into the ContextMenu:
Dim mnuPopUp As New ContextMenu() Dim mnuItem As MenuItem
For Each mnuItem In mnuOrderOptions.MenuItems ' The CloneMenu method ensures that the context menu and main menu items ' have the same event handlers. mnuPopUp.MenuItems.Add(mnuItem.CloneMenu()) Next
Me.ContextMenu = mnuPopUp
The last line here assigns the new context menu to the form’s ContextMenu
property. The only reason you should do this is to make sure that a reference to
the context menu is conveniently available when you need it-for example, in the
form’s event handler for a MouseDown event. Because the current form is
always available through the Me keyword, it provides a convenient place to
attach the ContextMenu reference.
The code for displaying a context menu in VB .NET is similar to that used
in VB 6, but not exactly the same:
Private Sub Form1_MouseDown(ByVal sender As System.Object, _ ByVal e As System.Windows.Forms.MouseEventArgs) Handles MyBase.MouseDown If e.Button = MouseButtons.Right Then Me.ContextMenu.Show(Me, New Point(e.X, e.Y)) End If End Sub
The best way to manage your context menus, and the best time to create
them, are up to you. Once again, the Upgrade Wizard won’t offer any help
beyond identifying the problem.
Control arrays present a particularly unpleasant example of what can go wrong
with migration. In Visual Basic 6, control arrays were often the best way to solve
problems. With a control array, numerous similar controls are placed into an
array. In VB6OrderMaker, control arrays allow the program to loop through a
series of controls and update them based on array information. For example,
you can copy pricing information into a series of text boxes using this syntax:
' VB 6 code. For i = 0 to UBound(PriceArray) txtPrice(i).Text = Val(PriceArray(i) Next i
In .NET, this approach can be replaced in various different incompatible
ways, including data binding, new list controls, or collection classes. Control
arrays, however, aren’t supported.
Control arrays also allowed a program to use a single event handler for
numerous similar controls, which was an extremely useful convenience. For
example, you could implement a set of dynamically highlighting labels, like this:
' VB 6 code. Private Sub Description_MouseMove(Index As Integer, Button As Integer, _ Shift As Integer, X As Single, Y As Single) Description(Index).ForeColor = &H800000 End Sub
In .NET, control arrays aren’t needed to handle multiple events. Instead,
you can use the Handles clause or the AddHandler statement to link up as many
controls as you want to a single event handler. You can then use the sender
parameter to interact with the control that fires the event, as discussed in
Chapter 4 of The Book of VB .NET.
Private Sub Highlight(ByVal sender As Object, ByVal e As MouseEventArgs) _ Handles lblLine1.MouseMove, lblLine2.MouseMove ' You can add more events to the Handles list, ' or use the AddHandler statement instead. Dim lbl As Label = CType(sender, Label) lbl.ForeColor = Color.RoyalBlue End Sub
To summarize: Control arrays were a quirky if useful tool in VB 6, but they
have been replaced with a more modern system in VB .NET. However, if you
import a program such as VB6OrderMaker that uses control arrays, the
Upgrade Wizard doesn’t convert them. Instead, it uses a special compatibility
class, depending on your control. For example, if you have a control array of
label controls, you’ll end up using Microsoft.VisualBasic.Compatibility.VB6.
LabelArray. This control allows VB .NET to “fake” a control array, with
predictably inelegant results.
This is an example of the Upgrade Wizard at its worst: importing legacy problems
from VB 6 into the .NET world. There’s no easy way to design around it in
VB 6, since control arrays are often a good design approach in that environment.
Unfortunately, this is one of the Upgrade Wizard’s fundamental limitations.
In Visual Basic 6, if you defined an object with the New keyword, it had the
strange ability to automatically recreate itself:
' VB 6 code. Dim objPerson As New Person Person.Name = "John" Person = Nothing ' The Person object is destroyed. Person.Name = "John" ' At this point, an empty Person object is reinitialized.
This was generally not what programmers expected, and it led to quirky
errors and memory waste. In Visual Basic .NET, the New keyword simply allocates
space for the object; it does not cause any unusual re- initializing behavior.
If you’ve made use of this trick, either deliberately or unwittingly in VB 6,
the code won’t work in .NET. When you try to use the destroyed object, you
will receive a null reference error. You’ll have to rewrite the preceding example
Dim objPerson As New Person() Person.Name = "John" Person = Nothing ' The Person object is destroyed.
Person = New Person() Person.Name = "John"
Re- initialization may be a minor detail, but it’s also one more potential
migration headache, particularly if the project you want to import has not been
created using best practices.
Visual Basic 6 had built in methods for drawing circles and other shapes directly
onto a form. In Visual Basic .NET, these graphical routines have been enhanced
and replaced by the GDI+ library, which you can access through the
System.Drawing namespaces. Once again, any original code you may have written
will need to be scrapped. This includes palette management, which
VB6OrderMaker used to ensure that the splash screen is displayed properly on
older 256-color monitors.
In Visual Basic 6, you might have used the Terminate event to perform automatic
cleanup tasks, such as closing a database connection or deleting a temporary
file. In Visual Basic .NET, this technique is a guaranteed to cause problems,
because the .NET framework uses non-deterministic garbage collection.
Garbage collection in VB .NET works in much the same way that garbage
collection works in many actual communities. In most neighborhoods, residents
can pinpoint the time that garbage is placed into the appropriate receptacle, but
they really have no idea when someone will be motivated to take it out. Similarly,
in .NET garbage collection may be put off until the system is idle, and
can’t be relied upon to release limited resources. You might find other surprises
if you use the Terminate event to try and interact with other forms in your
application. Generally, these techniques won’t work in VB .NET.
As with control arrays, a substantial difference in programming philosophies
underlies this problem. In Visual Basic 6, using the Terminate method was
a useful approach to making sure that cleanup was always performed the
moment the class was released. In Visual Basic .NET, you are better off adding a
Dispose method, and relying on the programmer to call this method after using
an object and just before destroying it. The Upgrade Wizard tries to encourage
this change: It places code from the Terminate event into a new, separate
method so that you can easily call it when needed. It also overrides the Finalize
method and adds a call to the new method to ensure that cleanup is performed:
Public Sub Class_Terminate_Renamed() ' Code goes here. End Sub
Protected Overrides Sub Finalize() Class_Terminate_Renamed() MyBase.Finalize() End Sub
This a good start, but you would be better off putting the code in a method
called Dispose (rather than Class_Terminate_Renamed, as the Upgrade Wizard
uses in our example). You’ll also still need to modify the code that uses the
class, because you’ll want to make sure that it calls the Dispose method before
destroying the object.
VarPtr, StrPtr, ObjPtr
These undocumented functions have traditionally been used by Visual Basic
experts to find the memory addresses where variables or objects were stored.
These functions allowed addresses to be passed to a DLL routine or to the Windows
API, which sometimes required this information. In Visual Basic .NET, you
hopefully won’t need to have this kind of low-level access to memory information,
as it complicates programs and can introduce obscure bugs. If, however,
you need to interact with a DLL or code component that needs an address, you
can still retrieve it-but you need to “pin down” the memory first. Pinning down
the memory ensures that the Common Language Runtime won’t try to move a
value between the time when you find its address and the time when the DLL
tries to use it. (This automatic movement feature is one of the ways by which the
.NET runtime attempts to improve performance.)
The following example creates and pins down a handle for an object
called MyObj. It uses a special type called GCHandle in the System.Runtime.
' You will need to import the namespace shown below to use this code as written. ' Imports System.Runtime.InteropServices
Dim MyGCHandle As GCHandle = GCHandle.Alloc(MyObj, GCHandleType.Pinned) Dim Address As IntPtr = MyGCHandle.AddrOfPinnedObject() ' (Invoke the DLL or do something with the Address variable here.)
' Allow the object to be moved again. MyGCHandle.Free()
Of course, the coding you use is up to you, but be aware that the Upgrade
Wizard will simply place an error flag if it finds the unsupported VarPtr, StrPtr,
or ObjPtr function.
Memory Storage for User-Defined Types
In Visual Basic 6, you could assume that user-defined types represented a contiguous
block of memory. This is not true for the .NET equivalent, structures,
which use a more efficient allocation of space. This change only has an effect if
you are using low-level DLLs or COM components (for instance, a legacy database
that expects data to be passed as a block of memory). To resolve this issues,
you’ll have to delve into some of .NET’s advanced data type marshalling features,
which are beyond the scope of this book, but detailed in the MSDN class
library reference under the System.Runtime.InteropServices namespace.
Optional parameters in VB .NET require default values, as explained in Chapter
3 of The Book of VB .NET. This is a relatively painless change. However, one consequence is that you
can’t rely on IsMissing to tell if a value has been submitted (although you can
check for your default value or use IsNothing, which is the Upgrade Wizard’s
automatic change). Keep in mind that overloaded functions often yield better
.NET options than do optional values.
Goto and Gosub
Support for these statements was scaled down in early beta versions of VB .NET,
but has been added back for the final release. But even though you can doesn’t
mean you should! Goto and Gosub are archaic programming concepts, and
using them is a direct road to programming nightmares. It’s a surprise that they
remained all the way through Visual Basic 6, let alone made the jump to the
Other New Behaviors
“New behavior” is the term that the Upgrade Wizard uses in its upgrade report
when it makes a change from one property or method to another that is similar,
but not identical. In many cases, this warning just represents an improvement to
a control. In other situations, it may represent a deeper problem that requires
Most experienced Visual Basic developers have spent significant time learning
their favorite controls, and know how to exploit all the associated quirks and
idiosyncrasies. This poses a problem for migration, where optimized code might
not work at all (or worse, might appear to work, but will then cause problems
under unusual future circumstances).
NOTE This issue raises a larger question. Namely, when is it safe to migrate a project? Even if
the process appears to succeed, you will need hours of testing to verify its success before you
can trust the updated application enough to release it into a production environment.
Preparing for VB .NET
Are the migration features in Visual Basic .NET impressive or depressing? It
really depends on how you look at it. Certainly, they represent a minor technological
feat. At the same time, many developers argue that they are useless for
using real VB 6 applications in the .NET environment. Even if you can import a
project, the result may be a rather ugly mess of old concepts, dressed up with
workarounds added by the Upgrade Wizard. This kind of application can be difficult
to work with and enhance, thus defeating the purpose of migration.
If you’re working on a Visual Basic 6 project today, your best choice is to
make rigorous use of class-based designs. If you take this protective step, then
even if you can’t import an entire project into .NET, you will at least be able to
import or recreate all of your business objects and data classes. Generally, data
classes are much easier to import than other components, because they don’t use
such VB 6-specific features as file or printer access, and they don’t directly create
user interface or require forms support. You can then import your business
objects, add a new .NET user interface tier (taking advantage of the latest features
in Windows Forms), and add lower-level data access components, if necessary, to
support ADO.NET or .NET file access through streams. The ability to upgrade is
one of the remarkable benefits of a structured three-tier design. The more you
can break your application down into functional units, the better chance you’ll
have to reuse at least some of its elements in the .NET environment.
What Comes Next?
This article has shown both the beauty and the ugliness of backward compatibility.
Visual Basic .NET is at its most elegant when dealing with COM interoperability,
allowing you to work with most components and even drop ActiveX controls
into your application without a second thought. However, the picture sours
if you need to import an average, mid-sized Visual Basic project, which is almost
guaranteed to crumble in the face of numerous incompatibilities.
As always, remember that just because a program is created in an older version
of Visual Basic it does not mean it needs to be brought to .NET. These
“legacy” programs will be supported on the Windows platform for years to
come. Conversely, just because an ActiveX control can be inserted into your
project doesn’t mean that you can’t reap more benefits by trying to achieve the
same effect using the class library. However, you’re likely to have at least some
third-party ActiveX controls that you don’t want to abandon in certain situations.
Remember to consider the tradeoff-if converting to .NET requires that
you import dozens of COM components, then you may be better off maintaining
your program in unmanaged Visual Basic 6.
If you are a COM guru (or are planning to become one), you will probably
want to explore .NET’s advanced COM support features. These include tools for
handling COM interoperability on your own, such as the System.Windows.
Forms.AxHost class and the types in the System.Runtime.InteropServices.
Be forewarned: Unless you are a war-hardened COM veteran, you won’t be able
to do much with these namespaces that you can’t do even better with the automatic
wrapper class generation features in Visual Studio .NET.
Matthew MacDonald, an author, educator and MCSD developer, has worked with Visual Basic and ASP since their inceptions. He is the author of The Book of VB .NET (No Starch Press) and ASP.NET: The Complete Reference (Osborne McGraw-Hill) and co-author of Programming .NET Web Services (O’Reilly).