Structure/Library Improvements

    Renaming Conflictive Declarations

    The renaming feature changes the name of an identifier and all of its references in order to avoid conflicts with another name. The different types of conflicts are listed here:

    Keywords

    The VBUC must rename the names that are the same as keywords from Visual Basic .NET and C#. Moreover, the VBUC should take into account the target language (Visual Basic.NET or C#) to recognize the keywords that apply for each case.

    Important Resources

    Download VBUC Free Trial
    Download  Now

    It's time to eradicate VB6
    ROI of Eradicating VB6

    8 Proven Tips for
    Planning a Successful Migration

    Learn More

    Original VB6 code

    Dim handles As Integer
    Sub this()
    handles = 0
    End Sub

    VBUC resulting VB.NET code

    Dim handles_Renamed As Integer
    Sub this()
    handles_Renamed = 0
    End Sub 

    VBUC resulting C#.NET code

    int handles = 0;
    void this_Renamed()
    {
    handles = 0
    } 

    Case sensitive issues (C#)

    Visual Basic 6 is a case insensitive language, but C# is not. The VBUC must correct the name references used with different cases to the case used in the declaration.

    Original VB6 code

    Dim myNum As Integer
    Function aFunc() As Boolean
    afunc = mynum != 0
    End Sub 

    VBUC resulting C#.NET code

    int myNum = 0;
    bool aFunc()
    {
    return myNum <> 0;
    } 

    Names with scope conflict

    The only recognized case is when a Type declaration element has the same as the type declaration. If this case is detected the element declaration must be renamed along with the references to this type element.

    Original VB6 code

    Form1.vb
    Type MyType
    MyType As String
    End Type 

    VBUC resulting VB.NET code

    Type MyType
    MyType_Renamed As String
    End Type 

    VBUC resulting C#.NET code

    struct MyType
    {
    String MyType_Renamed;
    } 

    Names that use class members from .NET

    This section applies for Forms and UserControls, mainly, because they could declare some member names that are part of the corresponding class in .NET (in this case System.Windows.Forms.Form & System.Windows.Forms.UserControl). These members must be renamed in order to avoid any conflict.

    Original VB6 code

    Form1.vb
    Sub Paint()
    End Sub 

    VBUC resulting VB.NET code

    Sub Paint_Renamed()
    End Sub 

    VBUC resulting C#.NET code

    void Paint_Renamed()
    {
    } 

    Controls with the same name as its container

    This case is very simple; it just applies if a container (as Form or User Control) contains a control with the same name. To resolve this conflict, the control must be renamed to <Control>_Renamed and all of its references.

    Original VB6 code

    Form1.vb
    Begin VB.CommandButton form1
    …
    End 

    VBUC resulting VB.NET code

    Dim form1_Renamed As System.Windows.Forms.Button 

    VBUC resulting C#.NET code

    System.Windows.Forms.Button form1_Renamed; 

    Avoid conflicts cutting namespaces

    Conflicts could be caused when the feature of cutting namespaces is activated. It happens when the resultant name is already used for another identifier. If this case happens, the namespace must be kept as the original, meaning the namespace is not cut.

    Original VB6 code

    Form1.vb
    Sub aSub()
    Dim Interaction As Integer
    Interaction = 0
    Beep
    End Sub 

    VBUC resulting VB.NET code

    Sub aSub()
    Dim Interaction As Integer = 0
    Microsoft.VisualBasic.Interaction.Beep
    End Sub 

    VBUC resulting C#.NET code

    void aSub()
    {
    int Interaction = 0;
    Microsoft.VisualBasic.Interaction.Beep();
    } 

    VB.Collection Optional Improvements

    By default VB.Collection objects are converted to the corresponding compatibility class in .NET libraries. This class provides the same functionality as its VB6 equivalent one. However, some performance gains can be obtained when the original collections are used in a regular way. Using collections in a regular way would mean that each collection object is accessed either only by position or only by a key value.

    The VBUC can be configured to apply an advanced collections conversion for regular collections. This feature analyses and identifies the actual ways in which each collection is used and decides whether to convert them to HashTable (when accessed by a key value) or to ArrayList (when accessed by index).

    Unsupported member/statement Handling

    Stubs generation

    For each library element in the original application that does not have an equivalent in .NET, an empty declaration (stub) is generated in a stub-dedicated source code file and into the converted project.  All the references to these non-converted elements are translated into references to their corresponding stub declarations. This strategy does not fully resolve the lack of .NET equivalent elements, since the stubs will require manual implementation, but it saves an important amount of time by achieving the following goals: a) it allows all the non-supported elements to compile, avoiding an important amount of compilation errors and helping to understand the required manual effort. b) For each non-supported element, a solution can be implemented in a single location in the target source code, instead of requiring changes for all its references.

    Reflection Helper

    This feature is used to solve references to some objects whose members and attributes where not totally clear and inferable for the typing engine in compilation time. For example, when a variant type is used in the original VB6 source code, the VBUC is capable of inferring the most appropriate type to migrate this item into .NET, avoiding the usage of castings and unnecessary conversions in the resulting code. However, the typing engine can get into trouble if the variable implements complex patterns of late binding in the current code scope, so that the translated code will have references to members and attributes of one particular object, and several lines below, references to other members and attributes of the same object that are not defined in the class because the object’s nature was not totally clear due to its usage. The VBUC will create a call to the reflection helper that will have the object name and the mentioned attribute as parameters, so the compilation will be successful in less time and the programmer will be able to identify the unsolved reference by looking for all the usages of the reflection helper methods. Those calls will have a method name that describes what the member was used for, because the helper contains a get, set, assign, call and more methods.