Set
m_MyProperty = Value
End Set
End Property
Visual Basic Forms to Windows Forms
Visual Basic.NET has a new forms package, Windows Forms, which has native support for accessibility and has an in-place menu editor. Your existing Visual Basic Forms are upgraded to Windows Forms.

Figure 2. Windows Forms in-place menu editor. (Click figure to see larger image.)
Interfaces
In previous versions of Visual Basic, interfaces for public classes were always hidden from the user. In Visual Basic.NET, they can be viewed and edited in the Code Editor. When your project is upgraded, you choose whether to have interface declarations automatically created for your public classes.
Upgrade Report and Comments
After your project is upgraded, an upgrade report is added to your project, itemizing any changes you will need to make to your upgraded code. Additionally, comments are added to your code to alert you to any potential problems. These comments show up automatically in the Visual Studio.NET Task List.

Figure 3. Upgrade comments are added to Visual Basic code as well as the Task List. (Click figure to see larger image.)
Programming Recommendations
This section provides recommendations for how you should write code to minimize the changes you will need to make after upgrading your project to Visual Basic.NET.
Use Early-Binding
Both Visual Basic 6.0 and Visual Basic.NET support late-bound objects, which is the practice of declaring a variable as the Object datatype and assigning it to an instance of a class at run time. However, during the upgrade process, late-bound objects can introduce problems when resolving default properties, or in cases where the underlying object model has changed and properties, methods, and events need to be converted. For example, suppose you have a Form called Form1 with a label called Label1; the following Visual Basic 6.0 code would set the caption of the label to "SomeText":
Dim o As Object
Set o = Me.Label1
o.Caption = "SomeText"
In Visual Basic.NET Windows Forms, the Caption property of a label control is now called Text. When your code is upgraded, all instances of the Caption property are changed to Text, but because a late-bound object is type-less, Visual Basic cannot detect what type of object it is, or if any properties should be translated. In such cases, you will need to change the code yourself after upgrading.
If you rewrite the code using early-bound objects, it will be upgraded automatically:
Dim o As Label
Set o = Me.Label1
o.Caption = "SomeText"
Where possible you should declare variables of the appropriate object type rather than simply declaring them as the Object datatype.
In the cases where you do use Object and Variant variables in your Visual Basic 6.0 code, we recommend you use explicit conversions when you assign the variables, perform operations on the variables, or pass the variables to a function. For example, the intention of the '+' operation in the following code is unclear:
Dim Var1 As Variant
Dim Var2 As Variant
Dim Var3 As Variant
Var1 = "3"
Var2 = 4
Var3 = Var1 + Var2 'UNCLEAR: What is the intention?
Should Var1 and Var2 be added as strings or integers?
The above example may result in a run-time error in Visual Basic.NET. Rewriting the final line to use explicit conversions ensures the code will work:
Var3 = CInt(Var1) + CInt(Var2) 'GOOD: explicit conversion
Visual Basic.NET supports overloading functions based on parameter type. For example, the Environ function now has two forms:
Environ( Expression As Integer) As String
Environ( Expression As String ) As String
Visual Basic.NET determines which function to call based on the parameter type. If you pass an integer to Environ(), the integer version is called; if you pass a string, then the string version is called. Code that passes a Variant or Object datatype to an overloaded function may cause a compile or runtime error. Using an explicit conversion, as in the following example, will mean your code will work as intended after it is upgraded to Visual Basic.NET:
Dim a As String
Dim v As Variant
v = "Path"
a = Environ(CStr(v)) 'GOOD: explicit conversion
Using explicit conversions of late bound objects is good coding practice. It makes the intention of the code easy to determine, and makes it easier for you to move your project to Visual Basic.NET.
Use Date for Storing Dates
Earlier versions of Visual Basic supported using the Double datatype to store and manipulate dates. You should not do this in Visual Basic.NET, because dates are not internally stored as doubles. For example, the following is valid in Visual Basic 6.0, but may cause a compile error in Visual Basic.NET:
Dim dbl As Double
Dim dat As Date
dat = Now
dbl = dat 'VB.NET: Double can't be assigned to a date
dbl = DateAdd("d", 1, dbl) 'VB.NET: Can't use Double in date functions
dat = CDate(dbl) 'VB.NET: CDate can't convert double to date
The .NET framework provides the ToOADate and FromOADate functions to convert between doubles and dates. However, when your project is upgraded to Visual Basic.NET, it is difficult to determine the intention of code that uses doubles to store dates. To avoid unnecessary modifications to your code in Visual Basic.NET, always use the Date datatype to store dates.
Resolve Parameterless Default Properties
In Visual Basic 6.0, many objects expose default properties, which can be omitted as a programming shortcut. For example, TextBox has a default property of Text, so instead of writing:
MsgBox Form1.Text1.Text
you use the shortcut:
MsgBox Form1.Text1
The default property is resolved when the code is compiled. In addition, you could also use default properties with late-bound objects, as in the following example:
Dim obj As Object
Set obj = Form1.Text1
MsgBox obj
In the late-bound example, the default property is resolved at run time, and the MsgBox displays the value of the default property of the TextBox as Text1.
Visual Basic.NET does not support parameterless default properties, and consequently does not allow this programming shortcut. When your project is upgraded, Visual Basic.NET resolves the parameterless default properties, but late-bound usages that rely on run-time resolution cannot be automatically resolved. In these cases, you will have to change the code yourself. An additional complication is that many libraries implement default properties using a property called _Default. _Default acts as a proxy, passing calls to the real default property. So, when your project is upgraded, some default properties will be resolved to _Default. The code will still work as usual, but it will be less understandable than code written explicitly using the actual property. For these reasons, try to avoid using parameterless default properties in your Visual Basic 6.0 code. Instead of writing:
Dim obj As Object
Set obj = Me.Text1
MsgBox obj 'Relying on default property
MsgBox Me.Text1 'Relying on default property
use:
Dim obj As Object
Set obj = Me.Text1
MsgBox obj.Text 'GOOD: Default property is resolved
MsgBox Me.Text1.Text 'GOOD: Default property is resolved
While parameterless default properties are not supported in Visual Basic.NET, default properties with parameters are supported. To understand the difference between the two types, consider that parametered default properties always have an index. An example is the default property of ADO recordset: the Fields collection. The code:
Dim rs As ADODB.Recordset
rs("CompanyName") = "SomeCompany"
rs!CompanyName = "SomeCompany"
is actually a shortcut for:
Dim rs As ADODB.Recordset
rs.Fields("CompanyName").Value = "SomeCompany"
rs.Fields!CompanyName.Value = "SomeCompany"
In this case, the Fields property is parametered, and so the usage is valid in Visual Basic.NET; however, the default property of the Fields property, Value, is parameterless, so the correct usage in Visual Basic.NET is:
Dim rs As ADODB.Recordset
rs("CompanyName").Value = "SomeCompany"
rs!CompanyName.Value = "SomeCompany"
This example and most other default properties are resolved for you when the project is upgraded, so resolving them in Visual Basic 6.0 is simply a good programming practice. However, you should avoid using default properties with the Object and Variant datatypes, as these cannot be resolved and you will have to fix the code yourself in the upgraded project.
Avoid Null Propagation
Previous versions of Visual Basic supported Null propagation. Null propagation supports the premise that when null is used in an expression, the result of the expression will itself be Null. In each case in the following example, the result of V is always Null.
Dim V
V = 1 + Null
V = Null + Right$("SomeText", 1)
V = Right("SomeText", 0)
Null propagation is not supported in Visual Basic.NET. The statement 1+Null will generate a type mismatch in Visual Basic.NET. Additionally, where Visual Basic 6.0 had two versions of the Left function-Left$ returning a string, Left returning a variant which could be Null-Visual Basic.NET only has one version, Left, which always returns a string.
In order to be compatible with both Visual Basic 6.0 and Visual Basic.NET you should always write code to test for Null instead of relying on Null propagation. Furthermore, in Visual Basic.NET, the following functions will no longer return Null:
Chr Mid
Command Oct
CurDir Right
Date RTrim
Environ Space
Error Str
Hex Time
LCase Trim
LTrim UCase
Null propagation is commonly used in database applications, where you need to check if a database field contains Null. In these cases you should check results using the function IsNull() and perform the appropriate action.
A related issue involves concatenating a string with a Null value. When programming with database objects, it is common practice to concatenate an "empty string" to a field to ensure that Null values are coerced to an empty string. For example:
MyString = rs!Field1 & ""
This technique is still supported in Visual Basic.NET. When a Null value is concatenated with an empty string (using the & operator), the result is an empty string.
Use Zero Bound Arrays
Visual Basic 6.0 allowed you to define arrays with lower and upper bounds of any whole number. You could also use ReDim to reassign a variant as an array. To enable interoperability with other languages, arrays in Visual Basic.NET must have a lower bound of zero, and ReDim cannot be used unless the variable was previously declared with Dim As Array. Although this restricts the way arrays can be defined, it does allow you to pass arrays between Visual Basic.NET and any other .NET language. The following example shows the restriction:
Dim a(1 To 10) As Integer 'LBound must be 0 in VB.NET
Dim v
ReDim v(10) 'Can't use ReDim without Dim in VB.NET
Dim b(10) As Integer 'GOOD: Creates an array of 11 integers
ReDim b(5) As Integer 'GOOD: Can ReDim previously Dimed var
A side effect is that Option Base 0|1 is removed from the language.
When your project is upgraded to Visual Basic.NET, any option base statements are removed from your code. If the array is zero bound, it is left unchanged. However, if an array is non-zero bound, then the lower bound is removed and a warning is inserted into the code, as in the following example:
Dim a(1 To 10) As Integer
changes to:
'UPGRADE_WARNING: Lower Bound of array a was changed from 1 to 0
Dim a(10) As Integer
In many cases, the upgraded code will work as it did before. However, if your application logic relies on the lower bound being 1, then you will need to make some modifications. Dim, ReDim, and LBound statements are marked with warnings to help you review the changes.
For this reason, you should use zero bound arrays in your Visual Basic 6.0 code, avoid using ReDim as an array declaration, and avoid using Option Base 1.
Use Constants Instead of Underlying Values
When writing code, try to use constants rather than relying on their underlying values. For example, if you are maximizing a form at run time, use:
Me.WindowState = vbMaximized 'Good: Constant name used
rather than:
Me.WindowStyle = 2 'Avoid using underlying value
Me.WindowStyle = X 'Avoid using variables
Likewise, use True and False instead of -1 and 0.
In Visual Basic.NET, the values and in some cases the names of some properties and constants have changed. When your project is upgraded to Visual Basic.NET, most constants are changed automatically for you; however, if you use underlying values or variables instead of the constant names, many cases cannot be upgraded automatically. Using constant names minimizes the number of modifications you have to do.
Arrays and Fixed-Length Strings in User-Defined Types
Due to changes made which allow Visual Basic.NET arrays and structures to be fully compatible with other Visual Studio.NET languages, fixed-length strings are no longer supported in the language. In most cases this is not a problem, because there is a compatibility class which provides fixed-length string behavior, so the code:
Dim MyFixedLengthString As String * 100
upgrades to the following:
Dim MyFixedLengthString As New VB6.FixedLengthString(100)
However, fixed-length strings do cause a problem when used in structures (also known as user-defined types). The problem arises because the fixed-length string class is not automatically created when the user-defined type is created. An additional problem is that fixed-size arrays are not created, either, when the user-defined type is created.
When your code is upgraded, user-defined types with fixed-length strings or arrays will be marked with a comment telling you to initialize the fixed-length string or array before using the user-defined type. However, you can shield yourself from this modification by changing your Visual Basic 6.0 user-defined types to use strings instead of fixed-length strings, and uninitialized arrays instead of fixed-size arrays. For example:
Private Type MyType
MyArray(5) As Integer
MyFixedString As String * 100
End Type
Sub Bar()
Dim MyVariable As MyType
End Sub
can be changed to:
Private Type MyType
MyArray() As Integer
MyFixedString As String
End Type
Sub Bar()
Dim MyVariable As MyType
ReDim MyVariable.MyArray(5) As Integer
MyVariable.MyFixedString = String$(100, " ")
End Sub
Avoid Legacy Features
Because they have been removed from the language, you should avoid using the following keywords:
" Def<type>
" Computed GoTo/GoSub
" GoSub/Return
" Option Base 0|1
" VarPtr, ObjPtr, StrPtr
" LSet
These are explained in more detail below.
Def<type>
In previous versions of Visual Basic, DefBool, DefByte, DefInt, DefLng, DefCur, DefSng, DefDbl, DefDec, DefDate, DefStr, DefObj and DefVar were used in the declarations section of a module to define a range of variables as a certain type. For example:
DefInt A-C
defined all variables beginning with the letter A, B, or C as an integer. Instead of using Def<type> statements, you should explicitly declare variables.
Computed GoTo/GoSub
Computed GoTo/GoSub statements take this form:
On x GoTo 100, 200, 300
These are not supported in Visual Basic.NET. Instead, you should use If statements, and Select Case constructs.
GoSub/Return
GoSub and Return statements are not supported in Visual Basic.NET. In most cases you can replace these with functions and procedures.
Option Base 0|1
Option Base 0|1 was used to specify the default lower bound of an array. As mentioned previously, this statement has been removed from the language since Visual Basic.NET natively only supports arrays with a zero lower bound. Non-zero lower bound arrays are supported through a wrapper class.
VarPtr, ObjPtr, StrPtr
VarPtr, VarPrtArray, VarPtrStringArray, ObjPtr and StrPtr were undocumented functions used to get the underlying memory address of variables. These functions are not supported in Visual Basic.NET.
LSet
In Visual Basic 6.0, the LSet statement could be used to assign a variable of one user-defined type to another variable of a different user-defined type. This functionality is not supported in Visual Basic.NET.
Windows APIs
Many APIs can be used exactly as they were in Visual Basic 6.0, with the caveat that you have to adjust your data types accordingly. The Visual Basic 6.0 Long datatype is now the Visual Basic.NET Integer datatype, and the Visual Basic 6.0 Integer datatype is now the Visual Basic.NET Short datatype. During the upgrade, these changes are made for you, and simple APIs work exactly the same as they did in Visual Basic 6.0. For example:
Private Declare Function GetVersion Lib "kernel32" () As Long
Function GetVer()
Dim Ver As Long
Ver = GetVersion()
MsgBox ("System Version is " & Ver)
End Function
changes to:
Private Declare Function GetVersion Lib "kernel32" () As Integer
Function GetVer()
Dim Ver As Integer
Ver = GetVersion()
MsgBox("System Version is " & Ver)
End Function
In addition to numeric datatype upgrades, Visual Basic 6.0 had a fixed-length string data type which is not supported in Visual Basic.NET, and which is upgraded to a fixed-length string wrapper class. In many cases in Visual Basic 6.0 you can perform the same action using a normal string. For example:
Private Declare Function GetUserName Lib "advapi32.dll" Alias _
"GetUserNameA" (ByVal lpBuffer As String, ByRef nSize As Long) As Long
Function GetUser()
Dim Ret As Long
Dim UserName As String
Dim Buffer As String * 25
Ret = GetUserName(Buffer, 25)
UserName = Left$(Buffer, InStr(Buffer, Chr(0)) - 1)
MsgBox (UserName)
End Function
can be better written using a normal string explicitly set to length 25 instead of a fixed-length string:
Dim Buffer As String
Buffer = String$(25, " ")
This is upgraded to Visual Basic.NET as follows:
Declare Function GetUserName Lib "advapi32.dll" Alias _
"GetUserNameA" (ByVal lpBuffer As String, ByRef nSize As Integer) As Integer
Function GetUser()
Dim Ret As Integer
Dim UserName As String
Dim Buffer As String
Buffer = New String(CChar(" "), 25)
Ret = GetUserName(Buffer, 25)
UserName = Left(Buffer, InStr(Buffer, Chr(0)) - 1)
MsgBox(UserName)
End Function
In some cases, Visual Basic.NET better handles passing strings to APIs, since you can optionally declare how you want strings to be passed using the ANSI and UNICODE keywords.
There are three cases where you may need to make some changes. The first is passing user-defined types that contain fixed-length strings or byte arrays to APIs. In Visual Basic.NET you may need to change your code, adding the MarshallAs attribute (from System.Runtime.InteropServices) to each fixed-length string or byte array in the user-defined type. The second case is using the As Any variable type in a Declare statement. This is not supported in Visual Basic.NET. Variables of type As Any were often used to pass a variable that was either a string or Null; you can replace this Visual Basic 6.0 usage by declaring two forms of the API, one with longs, one with strings. For example, the GetPrivateProfileString API has a parameter lpKeyName of type As Any:
Private Declare Function GetPrivateProfileString Lib "kernel32" Alias
"GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal
lpKeyName As Any, ByVal lpDefault As String, ByVal
lpReturnedString As String, ByVal nSize As Long, ByVal
lpFileName As String) As Long
You can remove the "As Any" by replacing the Declare with two versions; one that accepts a long, and one that accepts a string:
Private Declare Function GetPrivateProfileStringKey Lib "kernel32" Alias
"GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal
lpKeyName As String, ByVal lpDefault As String, ByVal
lpReturnedString As String, ByVal nSize As Long, ByVal
lpFileName As String) As Long
Private Declare Function GetPrivateProfileStringNullKey Lib "kernel32"
Alias "GetPrivateProfileStringA" (ByVal lpApplicationName As String,
ByVal lpKeyName As Long, ByVal lpDefault As String, ByVal
lpReturnedString As String, ByVal nSize As Long, ByVal
lpFileName As String) As Long
When you wish to pass the value Null to the API, you use the GetPrivateProfileStringNullKey version. Doing it this way means that the function upgrades to Visual Basic.NET.
The final area where you may need to make some changes is if you are using APIs that perform thread creation, Windows subclassing, message queue hooking, and so on. Some of these functions will cause a run-time error in Visual Basic.NET. Many of these APIs have equivalents in Visual Basic.NET or the .NET Framework. You will have to fix these on a case-by-case basis.
Considerations for Forms and Controls
Visual Basic.NET has a new forms package, Windows Forms. Windows Forms is largely compatible with the forms package found in Visual Basic 6; however, there are some key differences that are outlined below:
" Windows Forms does not support the OLE container control; you should avoid using this control in your Visual Basic 6.0 applications.
" There is no shape control in Windows Forms. Square and rectangular shapes will be upgraded to labels, while ovals and circles cannot be upgraded. You should avoid using these in your applications.
" There is no line control in Windows Forms. Horizontal and vertical lines are upgraded to labels. Diagonal lines are not upgraded, and you should avoid using them.
" Windows Forms has a new set of graphics commands that replace the Form methods Circle, CLS, PSet, Line, and Point. Because the new object model is quite different from Visual Basic 6.0, these methods cannot be upgraded.
" For the Timer control, setting the Interval property to 0 does not disable the timer; instead the interval is reset to 1. In your Visual Basic 6.0 projects, you should set Enabled to False instead of setting the Interval to 0.
" Windows Forms has two menu controls, MainMenu and ContextMenu, whereas Visual Basic 6.0 has one menu control, Menu, which can be opened as a MainMenu or a ContextMenu. Menu controls are upgraded to MainMenu controls, but you will not be able to use them as ContextMenus; you will have to recreate your ContextMenus.
" Windows Forms has no support for Dynamic Data Exchange (DDE).
" Windows Forms does not support the Form.PrintForm method.
" Although Windows Forms has support for drag-and-drop functionality, the object model is quite different from Visual Basic 6.0. Therefore, the Visual Basic 6.0 drag-and-drop properties and methods cannot be upgraded.
" The .NET framework has an improved Clipboard object (System.Windows.Clipboard) that offers more functionality and supports more clipboard formats than the Visual Basic 6.0 Clipboard object. However, because of differences between object models, clipboard statements cannot be automatically upgraded.
" To ensure your forms are upgraded to the right size, you should always use the default ScaleMode of twips in your applications. During the upgrade, Visual Basic.NET transforms your forms coordinates from twips to pixels.
" Windows Forms only supports true-type and open-type fonts. If your application uses other fonts, these fonts will be changed to the system's default font, and all formatting (size, bold, italic, underline) will be lost. This applies to the default VB6 font MS Sans Serif. For this reason, we recommend you use Arial instead of MS Sans Serif, wherever you have formatted text.