Overview

Our research shows that, with very few exceptions, any algorithm or operation that can be expressed in VB6 can also be expressed in C# or VB.NET.  However, there often several reasonable ways to express an algorithm or operation, and if you get 10 developers in a room you will get 10 different opinions about the “best” way.  gmStudio is designed with this in mind and it allows migration teams to configure the translation rules according to their unique standards.   We call this configuring gmStudio with custom language replacement rules.

The process for implementing custom language replacement rules follows an iterative four-step process:

1. Understand how legacy language elements are used by your application
2. Define your .NET language coding standards and conventions
3.  Design and implement the rules to migrate from legacy language conventions to .NET language standards
4.  Apply, refine and extend the rules for additional source codes as needed              

These four steps are described in more detail below.

1) Understand how legacy language elements are used by your application

The VB6 language and the intrinsic VB6 object model provides many types of services to VB6 applications.  A few examples are listed here:

• Logic: Intrinsic keywords, functions, and commands
• Object Model / Data Model Definition
• Custom Event Handling
• File IO, Database Access, Printing
• User Interface Forms/Controls and Graphics
• Error Handling
• Interfacing with COM and Win32 APIs
• Interfacing with the Operating System Services

The first step in customizing how gmStudio upgrades VB6 to .NET is to identify the specific VB6 language elements that provide services to your application and to understand, at a high level, how the services work.   

2) Define your Language replacement strategy

If your organization is already using .NET, you may already have coding standards for new .NET code and you should plan to follow those standards in upgraded legacy code as well. 

It is important that the coding standards are objective enough that upon review, you can know with certainty if the standards are being followed in your code, or not.  Manual review is critical, but when possible, automated review tools should also be used to help measure and report compliance with standards.

The second step in customizing language replacement is specifying new coding conventions and standards for .NET in a detailed and objective form.  

3) Design and implement the rules to rewrite VB6 language in .NET

Designing the rules for using .NET correctly is a manual task regardless of whether you plan to use tools to help you rewrite your code or not.  The rules must be considered and implemented at a detailed level based on the specific language elements and platform services used by your application.  In our methodology, the rules that direct language replacement are specified in two types of files:  Metalanguage Files, gmSL scripts, and Migration DLLs.

Metalanguage Files are XML documents that describe how the VB6 language elements map to C# or VB.NET.  The standard metalanguage files used by gmStudio are designed and maintained by Great Migrations and shipped with the product in the translator configuration files folder, [installdir]\support\trancfg. 

gmSL Scripts are files containing logic implemented in gmSL script code.  The logic allows a lower-level inspection of the original source code implementation and a more dynamic transformation of VB6 language elements map to C# or VB.NET.  See the RDO to SQLClient Sample for an example of gmSL.  The object oriented C# coding standard (SubSystem="ooc") and the VB6 forms to WPF feature (Subsystem="wpf") both use gmSL scripts to implement some of the more complex upgrade rules.

Migration DLLs are entry-point DLLs that implement complex transformations in C code.  Appendix Y provides some high level information on Migration DLLs, but a detailed discussion is beyond the scope of this document.  In general, gmSL scripts have taken the place of Migration DLLs.

4) Apply, refine and extend the rules to additional source codes as appropriate

The default metalanguage files shipped with gmStudio cover almost every aspect of popular VB6 dialect and you only need to customize those elements that you want to translate differently.  If you are migrating a large codebase you can expect to incrementally modify and refine your copy of the metalanguage files as you work though the source code units (VBP/ASP file).  The number of modifications should diminish to zero once you have processed a representative sampling of your code. 

Balancing manual and tool-assisted techniques

Of course there are limitations to what should be automated in a software re-engineering effort.  For example, it may not make sense to automate a particularly complex set of re-engineering operations that only impact one application function.  In these cases, the migration team should consider the following balanced approach: 

1. Leveraging gmStudio’s analytic capabilities, find out where and how the language elements are used in order to scope the redesign work and to plan customization tasks. 
2. If appropriate, use gmStudio to implement a partial migration by stubbing out, commenting out, or flagging specific code.
3. Finish and refine the transformation work manually
4. If desired, configure gmStudio to integrate hand-written code into your migration script solution to make the manual re-engineering a repeatable operation.

Appendix A: Example: Upgrading an Intrinsic Function

In this example, we look at how to customize the replacement of VB6’s Len function.

1)     Understand how legacy language elements are used by your application

In VB6, the Len function offers a convenient way to compute the length of a string.  Documentation for Len from the VB6 object browser says the following:

Function Len(Expression)
    Member of VBA.Strings
    Returns string length or bytes required to store a variable

gmStudio’s default translation of Len(x) is VBNET.Strings.Len(x). In default gmStudio translation conventions, VBNET is an alias for the Microsoft.VisualBasic namespace.  This namespace is distributed in Microsoft.VisualBasic.dll and contains an extensive set of classes that emulate VB6 runtime and VBA.  

public static int Len(string Expression)
 {
     if (Expression == null)
     {
         return 0;
     }
     return Expression.Length;
 }

You can use gmStudio’s reporting tools to see how your application uses the Len function.  The Source Scan Report can be run from the Search panel or the Reports menu.  Simply searching for “Len” will show were you use Len, but may also show some false matches.  A more precise Source Scan Report can be done using a more sophisticated regular expression; for example “@\bLen\(“ (the leading @ indicates case-sensitivity).  The most precise report for how and where you use Len will be obtained by running the Analytics References Report.  See the records in the Analytics References report having MemLibr=Basic,  MemClas=Vb6Function, and Memname=Len.

2)     Define your .NET language coding standards and conventions

Let’s assume that your coding standards do not allow use of the Microsoft.VisualBasic.Strings class and you want to use property notation, x.Length, instead of method notation, VBNET.Strings.Len(x).

3)     Design and implement the rules to migrate from legacy language conventions to .NET language standards

The next step in the process is to find the rule for expressing the Len operation and change it.  The easiest way to find a rule is to look for the .NET code pattern that you want to change in the metalanguage files.  You can do this with the Search Panel in gmStudio.  For this example, enter VBNET.Strings.Len in the search box on the left, check the [Lang] checkbox, and click [Run Search].  The results of this search are shown below:

The results show us that the rule for Len is in the VBASIC.xml file, which is located in the gmStudio installation folder, [installdir]\support\trancfg\lang.    The actual text of the rule for Len in VBASIC.xml looks like this

<MetaLanguage>
 <patterns>
    . . .
    <pattern id="VBF">
      <subcode id="Len">
         <vbn narg="1" code="Strings.Len(%1d)"/>
         <jvs narg="1" code="len(%1d)"/>
         <csh narg="1" code="VBNET.Strings.Len(%1d)"/>
      </subcode>

In order to make gmStudio author x.Length instead of VBNET.Strings.Len(x) we will change VBASIC.xml so that

<csh narg="1" code="VBNET.Strings.Len(%1d)"/>

 becomes                                                                 

<csh narg="1" code="%1d.Length"/>

%1d is a place holder for the expression that was being passed into Len in the original VB6 code.  Internally it corresponds to the first expression on the operation stack built by gmStudio when it processes and stores the VB6 code. 

An additional modification that can be useful when changing a method to a property is to add the status=”postfix” attribute.  In this example, status=’postfix’ directs gmStudio to put parentheses around the %1d token if needed. 

<subcode id="Len">
 <loc status="postfix" narg="1" code="%1d.Len()"/>
 <vbn narg="1" code="Strings.Len(%1d)"/>
 <jvs narg="1" code="len(%1d)"/>
 <csh narg="1" code="VBNET.Strings.Len(%1d)"/>
</subcode>

4)     Apply and refine those rules for additional source codes as needed

Typically a large, mature code will not meet the assumptions of every migration rule 100% and you should plan to consider alternatives and to refine or extend the rule to deal with variations.  This incremental refinement is an important aspect of our iterative methodology.

In this example, the new rule assumes that the type of original argument to Len has a Length property in .NET and that argument is not null at runtime.  The first assumption is easy to check using the C# compiler.  The second assumption can be checked by static analysis of the code and by runtime testing.  We know that the rule will not work for situations where the argument is a struct; in fact the resulting code will not even build.  A more appropriate translation of Len(struct), that still avoids using VBNET, is to use System.Runtime.Interop.Marshal.SizeOf().  

In this type of situation, a Migration DLL, or gmSL function, can be used to implement a rule that specifies x.Length is used for strings and Marshal.SizeOf(x) for is used for structs.   However,  when you encounter exceptions to your coding/upgrade standards, take time to see what the code is actually doing.  For example, in the case of code that uses Len with struct you will typically also find Win32 APIs calls or record-based file IO.  Both of these things warrant additional redesign as they move to .NET.   It may make more sense to rework that section of your code in a different way.   Also beware that VB6 language frequently provides high-level services that can only be reproduced by runtime routines that integrate several .NET operations.  The check for null in VBNET. Strings.Len is a good example of this. 

Appendix X: Activating a Custom Metalanguage Configuration

This appendix describes how to modify the metalanguage configuration so gmStudio will produce translations that use your custom language replacement rules.

Metalanguage Files

Metalanguage files are XML documents that direct gmStudio as it rewrites your VB6 program for .NET.

There are two types of Metalanguage files: default Interface Description Files (IDFs) and default Language Files.

• The Default IDFs are processed every time you run the translation process.
  
  The default IDFs are deployed in [installdir]\support\trancfg\idf
  
  To list and inspect the default IDFs:

1. 1. Open the Settings dialog by clicking the [Settings] button on the toolbar. 
   2. Click the [Configuration Files] tab
   3. Select the [Interface Descriptions] button

• The Default Language Files must be pre-processed by gmStudio to create the metalanguage information file (VB7Lang.vbi)
  
  The language script (VB7Lang.xml) directs gmStudio in processing default language files to create the metalanguage information file (VB7Lang.vbi)
  
  The translator StartUp file (gmBasic.xml) specifies the location of the metalanguage information file. 
  
  The default language files are deployed in [installdir]\support\trancfg\lang

To list and inspect the default Language Files:

1. 1. Open the Settings dialog by clicking the [Settings] button on the toolbar. 
   2. Click the [Configuration Files] tab
   3. Select the [Language] button

Customizing default interface description files

The [Configuration Files] tab on the Settings dialog is designed to help you inspect the metalanguage files and make a working copy in your project workspace.  The following instructions explain how this is done for a default IDF.

1. Open the Settings dialog by clicking the [Settings] button on the toolbar.
2. Click the [Configuration Files] tab
3. Copy the desired default IDF to your workspace.
   1. Click the [Interface Descriptions] button to list the default IDFs
   2. Click the desired default IDF, for example MigrationSupport.xml
   3. Click [Save As…] and save a copy of the file in the [workspace]\usr folder.

Customizing default language files

The [Configuration Files] tab on the Settings dialog is designed to help you inspect and manage all the files that play a role in configuring gmStudio.  The following instructions explain how to setup gmStudio to do custom language replacement.

Part 1: Activating project-specific metalanguage information

1. Open the Settings dialog by clicking the [Settings] button on the toolbar
2. Click the [Configuration Files] tab
3. Click the [Project] option in the [Translator Configuration] group box.

Clicking the [Project] option copies two files into your [workspace]\usr folder.

StartUp File (gmBasic.xml)

The StartUp file controls the global defaults for the translator including the location of the metalanguage information file. 

The Project option uses a version of the gmBasic startup file that has the metalanguage attribute set so that the translator will use the language information file in your workspace.

<Startup metalanguage="..\usr\VB7Lang.vbi">

Language Information Script (VB7Lang.xml)

The Language Information Script indicates which default language files should be processed to create the language information file.  The Project option uses a version of the script that can be edited to specify that your custom language files should be used instead of the default files.

Part 2: customizing default language files

1. Identify the metalanguage file that you wish to update and make a copy of the file in your workspace -- if you have not already done so.  For example, assume you want to modify the VBASIC.xml file. 
   
   
   1. Click [Language Files] to list the default language files
2. Modify the VBASIC.xml file in your work space user folder so as desired.  For example.
   
   
   1. Select VBASIC.xml in the file list
   2. Right-Click and select [Activate Project Specific Copy] to save a copy of the VBASIC.xml in the [workspace]\usr\lang folder
   Activating a project specific copy will also modify the VB7Lang.xml file in your workspace so that it will reference the VBASIC.xml in your workspace instead of the one in the default metalanguage folder. 
3. Select User files on the setting Dialog then select your copy of the VBASIC.XML file.  The click the \[Editor] button to open the file for editing and make changes.  
4. Rebuild the metalanguage information file by clicking the [Update Translator Configuration] button.  
   
   This processes the VB7Lang.xml script and display the Translator Configuration Build Log into the text box. 
   If the process is successful, the listing will show the directory listing for the new VB7Lang.VBI file in your workspace.

Part 3: comparing your custom files to default

You can compare your customized metalang files to the corresponding default version by selecting the file and right-clicking \[Compare to Default].  

This feature can be helpful to merge default file changes after you have installed an gmStudio upgrade (See Appendix Z).

Appendix Y: Migration Dlls

Migration DLLs extend and alter the behavior of the gmStudio translator.   Migration DLLs can manipulate the information about the system at the lowest level: symbol tables and operation streams.   Migration DLLs can also be used to extend the gmBasic scripting language, for example, to develop specialized analysis, reporting, and  code generation tools.  Migration DLLs allow migration teams to make the translator do things that cannot be easily specified using the declarative refactoring statements or the gmStudio scripting language.

Migration DLLs contain "handlers".  These are subroutines invoked by the translator when various "migration events" occur during processing.  There is a large set of predefined migration events as well as a facility for attaching migration events to the specific types and members in COM libraries and to specific application types and variables.   There is also an extensive gmStudio API that facilitates interacting with the translator and the system model in migration event handlers.

Migration DLLs can be coded with Visual Studio using C, Managed C++, C#, and VB.NET.   The system programming techniques and meta-programming concepts needed to develop migration DLLs are somewhat advanced.  We typically develop the Migration DLLs for our customers; but we also offer an SDK and Training Package for teams who want to develop Migration DLLs in house.

Appendix Z: Upgrading System Defaults

From time to time a new release of gmStudio will include changes to the default metalanguage scripts.  These changes will be baked" into the system default metalanguage file (vb7lang.vbi) and will be used by default in new translation workspaces. However, if you have a workspace that is using a project-specific metalanguage configuration, you MUST sync up your custom metalanguage scripts to be compatible with gmStudio failing to do this will frequently cause the translator to terminate abnormally lead or produce malformed results.

Syncing up your custom metalanguage scripts with the new system defaults is the same as any other code merging operation:

For each of new system default scripts, check to see if you are using a custom script in your project workspace.  If you are not using a custom script, move onto the next script.  But, it you have have a custom copy of a script, merge the new system default into your custom copy. The easiest way to do this is with a file comparison/merge tool such as Beyond Compare.  Once you have synced all of your custom metalanguage scripts with the new system default script, you should rebuild your project specific metalanguage file using the Settings form.