Unused classes, fields, and methods are tagged with a special UPGRADE_INFO comment, which encourages the developer to whether the member is actually unnecessary and possibly delete it from the original VB6 application.

    Public Sub Test() 	
        ' UPGRADE_INFO (#0501): 'Test' member isn't used anywhere in current application. 
        ' ... 
    End Sub

The code analyzer is smart enough to mark as unused those methods that invoke each other but don’t belong to any possible execution path. For example, suppose that method Test references Test2. In this case, VB Migration Partner emits a slightly different message:

    Public Sub Test2() 	
        ' UPGRADE_INFO (#0511): The 'Test' member is referenced only by members that 
        ' haven't found to be used in the current project/solution. 
        ' ...
    End Sub

Bear in mind that code analysis can account only for members that are referenced by means of a strongly-typed variable. If the member is referenced exclusively via a Variant, Object, or Control variable, the member is mistakenly considered to be “unused”. A similar problem occurs if the member is referenced only though a CallByName method. In such cases you can tell VB Migration Partner not to include the field, property, or method in the list of referenced members by means of the MarkAsReference pragma:

    '## Test.MarkAsReferenced 
    Public Sub Test() 	
        ' ... 
    End Sub

Another case when VB Migration Partner can mistakenly find “unused” members is when migrating an ActiveX DLL or ActiveX EXE project. If you are migrating such a project individually, most of the public properties and methods of its public classes and controls are never referenced elsewhere. Even if you migrate the project as part of a group that contains a client project, chances are that the client project doesn’t reference each and every public member of all public classes of the ActiveX DLL or EXE project.

To cope with this situation, VB Migration Partner supports the MarkPublicAsReferenced pragma, which automatically marks as referenced all the public members in current class. You can apply this pragma at the project level, too, in which case all public members of all public classes in the project are marked as referenced:

    '## project:AddPublicAsReferenced

Because of late-bound references and accesses from external processes, VB Migration Partner doesn’t automatically delete unused members. However, we provide an extender that deletes unused Declare and Const statements, which are never accessed in late-bound mode or from external projects. You can enable this feature in the Extenders tab of the Tools-Options dialog box.

By default, VB6’s default passing mechanism is by-reference, and many developers mistakenly omitted the ByVal keyword for parameters that were meant to be passed by value. VB Migration Partner emits an UPGRADE_INFO remark for all parameters that are passed byreference but aren’t assigned in the method itself, nor are passed by-reference to methods that modify them. Let’s consider the following VB6 code:

    Public Sub Test(n1 As Integer, ByRef n2 As Integer, n3 As Integer)  	
        Test2 n1, n2, n3 
    End Sub 
    
    Public Sub Test2(ByVal n1 As Integer, ByRef n2 As Integer, n3 As Integer)  	
        Debug.Print n1 	
        Debug.Print n2 	
        Get #1, , n3 
    End Sub

Parameter n1 is never assigned in method Test and can’t be modified by Test2 because it is passed into a ByVal parameter. Parameter n2 is passed to a ByRef parameter of Test2 method, yet Test2 never modifies it. Finally, parameter n3 is not flagged is passed to Test2 method in a ByRef parameter and it is indeed modified inside that method. Here’s is the code that VB Migration Partner emits:

    Public Sub Test(ByRef n1 As Short, ByRef n2 As Short, ByRef n3 As Short) 
        ' UPGRADE_INFO (#0551): The 'n1' parameter is neither assigned in current method nor 
        ' is passed to methods that modify it. Consider changing its declaration using the 
        ' ByVal keyword. 
        ' UPGRADE_INFO (#0551): The 'n2' parameter is neither assigned in current method nor 
        ' is passed to methods that modify it. Consider changing its declaration using the 
        ' ByVal keyword. 
        Test2(n1, n2, n3) 
    End Sub 
    
    Public Sub Test2(ByVal n1 As Short, ByRef n2 As Short, ByRef n3 As Short) 
        ' UPGRADE_INFO (#0551): The 'n2' parameter is neither assigned in current method nor 
        ' is passed to methods that modify it. Consider changing its declaration using the 
        ' ByVal keyword. 
        Debug.WriteLine(n1) 
        Debug.WriteLine(n2) 
        FileGet6(1, n3) 
    End Sub 

In general, you should consider changing the passing semantics of parameters flagged with the special UPGRADE_INFO remark, because ByVal parameters are often faster than ByRef parameters. The only exception to this rule is structures, and for this reason VB Migration Partner never applies this remark to Structures.

Even more important, replacing ByRef parameters with ByVal parameters often avoids hard-to-find bugs in the VB.NET code.

To help you in applying the ByVal keyword where needed, VB Migration Partner supports the UseByVal pragma, which can be applied at the project, file, or method level. This pragma takes one argument, chosen among the following values:

Yes: VB Migration Partner applies the ByVal keyword with unassigned parameters that implicitly use by-reference semantics (i.e. have no explicit ByRef or ByVal keyword).
Force: VB Migration Partner applies the ByVal keyword with all unassigned parameters that use by-reference semantics, even if an explicit ByRef keyword is found.
No: VB Migration Partner never applies the ByVal keyword. (This is the default behavior, yet this option can be useful to override another pragma at a broader scope.)

Let’s see how this pragma can affect the Test and Test2 methods seen in previous example:

    Public Sub Test(n1 As Integer, ByRef n2 As Integer, n3 As Integer)  	
        '## UseByVal Yes 
        Test2 n1, n2, n3 
    End Sub 
    
    Public Sub Test2(ByVal n1 As Integer, ByRef n2 As Integer, n3 As Integer)  	
        '## UseByVal Force 
        Debug.Print n1 	
        Debug.Print n2 	
        Get #1, , n3 
    End Sub

Here’s the result from VB Migration Partner:

    Public Sub Test(ByVal n1 As Short, ByRef n2 As Short, ByVal n3 As Short) 	
        ' UPGRADE_INFO (#0551): The 'n2' parameter is neither assigned in current method nor 
        ' is passed to methods that modify it. Consider changing its declaration using the 
        ' ByVal keyword. 
        Test2(n1, n2, n3) 
    End Sub 
    
    Public Sub Test2(ByVal n1 As Short, ByVal n2 As Short, ByRef n3 As Short) 	
        Debug.WriteLine(n1) 	
        Debug.WriteLine(n2) 	
        FileGet6(1, n3) 
    End Sub

All parameters that were flagged by the special remark in previous example are now defined with the ByVal keyword (and therefore have no remark associated with them), except the n2 parameter of Test method, because it was defined with an explicit ByRef keyword and we didn’t use the “Force” option in that method.

Sections of unreachable code inside methods are tagged with a special UPGRADE_INFO comment; examples of such sections are those that immediately follow Exit Sub, Exit Function, and Exit Property statements:

    Public Sub Test() 
        ' ... 
        Exit Sub 
        ' UPGRADE_INFO (#0521): Unreachable code detected 
        Test2() 
    End Sub

Unreachable code detection in current version of VB Migration Partner accounts neither for conditional structures (e.g. If blocks) nor for unhandled errors. For example, in the following example the code analyzer fails to detect that the call to Test2 is unreachable:

    Public Sub Test(ByVal x As Integer) 
        If x < 0 Then 
            ' ... 
            Exit Sub 
        Else 
            Err.Raise 99 
        End If 
        
        Test2() 
    End Sub

Many VB6 developers define a Class_Terminate event handler just to set class-level variables to Nothing. Such assignments are superfluous – because the object is released anyway when the “Me” object is destroyed, but this coding style doesn’t harm in VB6.

When you convert this code to VB.NET, however, the Class_Terminate handler is translated into a Finalize method. As you may know, finalizable VB.NET classes are less efficient than standard classes, therefore you should avoid to declare the Finalize method unless it is strictly necessary. To help you follow .NET Framework coding best practices, VB Migration Partner emits an UPDATE_INFO remark when a Class_Terminate event handler can be safely removed, as in this case:

    Private col As New Collection 	 
    
    ' UPGRADE_INFO (#0541): This 'Class_Terminate' method appears to be useless. Please 
    ' delete it in the original project and restart migration.
    
    Private Sub Class_Terminate_VB6() 	
        col = Nothing 
    End Sub

Many VB6 developers like to reset error handling on exiting a method, as in this code:

    Public Sub Test(n1 As Integer, ByRef n2 As Integer, n3 As Integer)
        On Error GoTo ErrorHandler
        Debug.Print n1, n2, 3
        
    ErrorHandler:
        ' ... 
        ' reset error handling before exiting
        On Error GoTo 0
    End Sub

It turns out that the On Error GoTo 0 statement is useless in this case, because the VB error handling is always reset on exiting a method. For this reason, VB Migration Partner remarks out the statement:

    Public Sub Test(ByRef n1 As Short, ByRef n2 As Short, ByRef n3 As Short)
        On Error GoTo ErrorHandler 
        DebugPrintLine6(n1, TAB(), n2, TAB(), 3)
    ErrorHandler:
        ' ... 
        ' IGNORED: On Error GoTo 0 
    End Sub

Some VB6 developers – especially those who have written code in other languages, such as C or Pascal – incorrectly assume that the following statement defines three 32-bit variables:

    Dim x, y, z As Long

Instead, the statement defines two Variant variables and one Long variable. (More precisely, the type of x and y variables depends on the active DefXxx directive and is Variant only if no such a directive exist in current file.) VB Migration Partner translates the variable declarations correctly, but adds a warning so that you can spot the probable mistake:

    ' UPGRADE_INFO (#0561): The 'x' symbol was defined without an explicit "As" clause.
    Dim x As Object = Nothing
    ' UPGRADE_INFO (#0561): The 'y' symbol was defined without an explicit "As" clause.
    Dim y As Object = Nothing
    Dim z As Integer

A similar warning is emitted for functions, properties, and parameters that lack an explicit “As” clause.

In general, VB.NET is slower than VB6 at concatenating strings. As a matter of fact, you should avoid string concatenations inside a time-critical loop, as in this case:

    Dim s As String
    Dim n As Integer
    For n = 1 To 10000
        s = s & Str(n) & ","
    Next

VB Migration Partner helps you optimize your code by marking string concatenations inside a For, While, or Do loop with a special migration warning. This is how the previous code is converted to VB.NET:

    Dim s As String = ""
    Dim n As Short
    For n = 1 To 10000
        ' UPGRADE_INFO (#0571): String concatenation inside a loop. 
        ' Consider declaring the 's' variable as a StringBuilder6 object.
        s = s & Str6(n) & ","
    Next

You should scrutinize all upgrade infos #0571 and decide whether you should change the type of the string variable into System.Text.StringBuilder or the special StringBuilder6 type exposed by VB Migration Partner’s support library. The latter type is usually preferable because it minimizes the code edits that are necessary to deliver working code:

    Dim s As StringBuilder6 = ""
    ' (remainder of code as before)

You can also use a SetType pragma to replace the data type from inside the VB6 code:

    '## s.SetType StringBuilder6
    Dim s As String

VB6 projects often contain references to type libraries that aren’t directly used by the current project. For example, if you create a new VB6 project by selecting the “Data Project” or the “VB Enterprise Edition Controls” template, Visual Basic 6 creates a project that references a number of type libraries that you don’t actually use. VB Migration Partner detects all unreferenced type libraries and lists them at the top of one of the VB.NET source files:

    ' UPGRADE_INFO (#0571): The 'DDSLibrary' type library is never used in current project. 
    ' Consider deleting it from VB6 project references.

Notice that the unused reference is not removed automatically from the converted VB.NET project. It’s up to the developer to decide whether the type library is truly unnecessary and remove it manually from the original VB6 project. This manual fix ensures that the VB.NET project contains only the references that are strictly necessary and speeds up the conversion process.

VB6’s Function and Property Get procedures return a value to their caller by assigning the value to a local variable named after the procedure itself, as in this code:

    Function GetData() As Integer
        …
        If x > 0 Then
            GetData = x
            Exit Function
        End If
        …
    End Function

VB Migration Partner is able to collapse the assignment and the Exit statement into a VB.NET Return statement if it’s safe to do so:

    Function GetData() As Short
        …
        If x > 0 Then
            Return x
        End If
        …
    End Function

This feature is quite sophisticated and works as expected even in more intricate cases, as in the following example:

    Function GetData() As Integer 	
        … 	
        If x > 0 Then 		
            If y > 0 Then 			
                GetData = y 		
            Else 			
                GetData = x 		
            End If  		
            Exit Function 	
        End If 	
        … 	
        GetData = 0
    End Function

which translates to:

    Function GetData() As Short 	
        … 	
        If x > 0 Then 		
            If y > 0 Then 			
                Return y 		
            Else 			
                Return x 		
            End If  		
            Exit Function 	
        End If 	
        … 	
        Return 0 
    End Function

Notice that the Exit Function keyword is left in code and must be removed manually.

VB Migration Partner attempts to merge a local variable’s declaration with its initialization. For example, the following VB6 code:

    Dim d As Double, i As Integer, v As Long, o As Object
    d = 1.8
    i = 11
    …
    If d = 0 Then v = 111

is translated to VB.NET as

    Dim d As Double = 1.8
    Dim i As Integer = 11
    Dim v As Long
    Dim o As Object = Nothing
    …
    If d = 0 Then v = 111

In this example, the d and i variables can be safely declared and initialized in a single statement, whereas the v variable can’t. This feature is enabled only for strings and scalar variables; Object and other reference type variables are always explicitly initialized to Nothing to prevent the VB.NET compiler from complaining about uninitialized variables that might throw a NullReference exception.

VB Migration Partner takes a conservative approach and doesn’t merge a variable declaration with the first assignment to that variable if the code block between these two statements includes keywords that change execution flow, for example method calls or Select Case blocks, or if the value being assigned isn’t constant.

You can force variable initialization by adding a MergeInitialization pragma for that specific variable. Consider this code fragment:

    '## n1.MergeInitialization Force
    Dim n1 As Integer, n2 As Integer  
    n1 = 10 + GetValue() 
    n2 = 11 + n1

In this case the MergeInitialization Force pragma informs VB Migration Partner that the call to the GetValue method can be safely included in the variable initialization. The code generator merges the declaration and initialization of n1 variable, because of the MergeInitialization pragma, but not of n2 variable:

    Dim n1 As Short = 10 + GetValue() 
    Dim n2 As Short  
    n2 = 11 + n1

You can disable this optimization at the project, file, method, or variable level by means of the following pragma:

    '## MergeInitialization No

VB Migration Partner is able to replace plain assignment symbols with compound assignment operators, such as += or /=. For example, the following code:

    sum = sum + 1.8 
    value = value \ 2 
    text = text & "abc" 
    Label1.Caption = Label1.Caption & "." 
    Label2 = Label2 + "<end>"

is translated to VB.NET as follows:

    sum += 1.8 
    value \= 2 
    text &= "abc" 
    Label1.Caption &= "." 
    Label2.Caption &= "<end>"     ' notice that default property has been resolved

When the original VB6 code appends a string to the Text property of a TextBox, MaskEdBox, RichTextBox, or WLText control, VB Migration Partner can translate this operation into a more efficient call to the AppendText method. This is a special case of the pattern described at previous point:

    Me.Text1.Text = Me.Text1.Text & "<end>" 
    Text2 = Text2 + "<end>"

becomes

    Me.Text1.AppendText("<end>")
    Text2.AppendText("<end>")

VB Migration partner is able to drop If blocks if the Then and the Else blocks contain the same code. Such blocks can be produced, for example, by a conversion of a VB6 property. A VB6 Variant propery can have both the Property Let and Property Set blocks, if the property can be assigned either a scalar or an object value, as in this example:

    Private m_Tag As Variant
          
    Property Get Tag() As Variant
        If IsObject(m_Tag) Then
            Set Tag = m_Tag
        Else
            Tag = m_Tag
        End If
    End Property
    
    Property Let Tag(ByVal newValue As Variant)
        m_Tag = newValue
    End Property
   
    Property Set Tag(ByVal newValue As Variant)
        Set m_Tag = newValue
    End Property

Converting this property literally delivers the following VB.NET code:

    Private m_Tag As Object
    
    Public Property Tag() As Object
        Get
            If IsObject6(m_Tag) Then
                Return m_Tag
            Else
                Return m_Tag
            End If
        End Get
        Set(ByVal newValue As Object)
            If IsObject6(newValue) Then
                m_Tag = newValue
            Else
                m_Tag = newValue
            End If
        End Set
    End Property

VB Migration Partner detects that the Then and the Else portions of the If blocks contain the same executable statements and can simplify them as follows:

    Private m_Tag As Object
    
    Public Property Tag() As Object
        Get
            Return m_Tag
        End Get
        Set(ByVal newValue As Object)
            m_Tag = newValue
        End Set
    End Property

If the control or component is authored with VB6 and you have its source code, in most cases adding support for that control or component is a simple process: just run VB Migration Partner to migrate the ActiveX DLL or ActiveX Control project that contains the user control, going through the usual convert-test-fix cycle. When the migrated project finally works correctly, you might want to polish the VB.NET code.

For example, most VB6 user controls have been created by means of the ActiveX Control Interface Wizard, which generates tons of VB6 code whose only purpose is remedying the lack of inheritance in VB6. For example, assume that you are migrating a VB6 user control that works like an enhanced TextBox control. Such a control surely includes a Text property that does nothing but wrapping the property with same name of the inner TextBox control:

    Public Property Get Text() As String
        Text = Text1.Text
    End Property

    Public Property Let Text(ByVal New_Text As String)
        Text1.Text() = New_Text
        PropertyChanged "Text"
    End Property

This property is translated correctly to VB.NET, however it is unnecessary and could be dropped without any negative impact on the migrated project. The simplest way to fix this code is by means of a couple of OutputMode pragmas:

    '## OutputMode Off 
    Public Property Get Text() As String
        Text = Text1.Text 	
    End Property 	
    
    Public Property Let Text(ByVal New_Text As String)
        Text1.Text() = New_Text
        PropertyChanged "Text"
    End Property 	
    
    '## OutputMode On

Also, you can use PostProcess pragmas to delete special remarks added by the ActiveX Control Interface Wizard, as well as calls to the PropertyChanged method (which are useless under VB.NET).

AxWrapperGen is a tool that is part of the VB Migration Partner package. (You can find it in the main installation directory, which by default is C:\Program Files\Code Architects\VB Migration Partner.) It is a command-line utility, therefore you must open a command window and run AxWrapperGen from there.

AxWrapperGen’s main purpose is allowing VB Migration Partner to support compiled 3rd-party ActiveX controls. AxWrapperGen takes one mandatory argument, that is, the path of the .ocx file that contains the ActiveX control to be wrapped. For example, the following command creates the wrapper class for the Microsoft Calendar control (and of course assumes that such control is installed in the c:\windows\system32 folder):

    AxWrapperGen  c:\windows\system32\mscal.ocx

(Notice that we are using the MSCAL.OCX control only for illustration purposes, because VB Migration Partner already supports this control.) If the file name contains spaces, you must enclose the name inside double quotes. AxWrapperGen is able to convert multiple ActiveX controls in one shot

    AxWrapperGen  c:\windows\system32\mscal.ocx   "c:\windows\system32\threed32.ocx"

By default, AxWrapperGen generates a new project and solution named AxWrapper in current directory. You can change these default by means of the /out switch (to indicate an alternative output directory) and /project switch (to set the name of the new project and solution):

    AxWrapperGen  c:\windows\system32\mscal.ocx   /out:c:\myapp /project:NetCalendar

By default, AxWrapperGen generates VS2005 projects. You can generate VS2008 projects by adding a /version option:

    AxWrapperGen c:\windows\system32\mscal.ocx /version:2008

AxWrapperGen runs the AxImp tool – which is part of the .NET Framework SDK – behind the scenes, to generate two DLLs that work as the RCW (Runtime Component Wrapper) for the selected control. For example, the mscal.ocx control generates the following two files: msacal.dll and axmsacal.dll. You can specify the following five options, which AxWrapperGen passes to AxImp: /keyfile, /keycontainer, /publickey, /delaysign, and /source. For more information, read .NET Framework SDK documentation.

At the end of generation process, AxWrapperGen runs Microsoft Visual Studio and loads a solution that contains one VB.NET class library (DLL) project, containing a pair of classes for each ActiveX control:

• The first class of each pair works as a wrapper for the original ActiveX control.
• The second class of each pair provides support during the migration process.

In our example, the MSCAL.OCX file contains only one ActiveX control, therefore only two classes will be created: the class named VB6Calendar inherits from AxMSACAL.AxCalendar and wraps the ActiveX control; the second class is named VB6Calendar_Support And inherits from VB6ControlSupportBase. This class will be instantiated and used by VB Migration Partner during the migration process, but not at runtime during execution.

Before compiling the solution, check the “Instructions” region at the top of each class. In most cases, the project that AxWrapperGen utility creates compiles correctly at the first attempt. The compilation process creates a DLL that you must manually copy into the VB Migration Partner’s main directory.

In some cases, however, you need to tweak the code that has been created. More precisely, if any property or method has to do with graphic units – in other words, it represents a width or height and is therefore affected by the container’s ScaleMode property – you need to shadow the original member and create your own. For example, the DataGrid control exposes a property named RowHeight, which requires this treatment. This is the code that implements the required fix:

    <Localizable(True)> _
    <Category("Appearance")> _ 	
    Public Shadows Property RowHeight() As Single
        Get
            Return VB6Utils.FromPixelY(Me, CInt(MyBase.RowHeight), False, True)
        End Get
        
        Set(ByVal value As Single) 
            MyBase.RowHeight = VB6Utils.ToPixelY(Me, value, False, True)
        End Set
    End Property

The bulk of the work is done inside the FromPixelY and ToPixelY methods of the VB6Utils class, contained in the CodeArchitects.VBLibrary.dll. These methods check the current ScaleMode value and perform all the required conversions. (Of course, the class exposes also the FromPixelX and ToPixelX methods, for measures along the X axis.)