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:
These four steps are described in more detail below.
The VB6 language and the intrinsic VB6 object model provides many types of services to VB6 applications. A few examples are listed here:
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.
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.
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.
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.
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:
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.
Decompiling Microsoft.VisualBasic.dll shows that VBNET.Strings.Len is
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)"/>
<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.
See Appendix X for instruction on how to modify metalanguage files.
An alternative to modifying the standard language dialects (i.e., vbn, csh) directly is to add your own custom coding standard as an upgrade SubSystem. First a three-character subsystem name must be added to the Dialects element in the enumerations.xml metalanguage file.
Next, the subsystem name is used to implement your custom upgrade rules for the specific operations you want to customize.
For example, the loc subsystem implements an object-oriented C# codnig standard. If you search the language files for "<loc" you will see that it contains an extensive set of customizations. Here is the one for Len:
You can load up to 5 subsystems in your migration script to create a hierarchy of custom rules. See the VB.NET versions of the standard samples to see how multiple subsystems can be applied.
The core language dialects: csh, vbn, and all will always be loaded an applied for patterns that are not over-ridden by a user subsystem.
More sophisticated, dynamic subsystems, can be implemented by adding a gmSL scripts to the system configuration. See for example oocSubsystem.gmsl and wpfSubSystem.gmsl in the system metalanguage folder.
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.
Balancing manual and automated work is a central tenet of the tool-assisted rewrite methodology.
You should apply rules in a manner that fits the needs of your application and use a variety of techniques including using gmStudio to systematically integrate hand-written code with the migration solution.
This appendix describes how to modify the metalanguage configuration so gmStudio will produce translations that use your custom language replacement rules.
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.
To list and inspect the default Language 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.
Once a default IDF file exists in your workdspace\usr folder it will take precedence over the default copy. This behavior is governed by gmStudio’s configuration folder search rules: Target before Local before System before Language.
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.
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.
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.
Once you have modified the gmBasic.xml and the VB7Lang.xml files is in your workspace, clicking the [Update Translator Configuration] button will create a new metalanguage information file (VB7Lang.vbi) in your workspace. This customized file will take precedence over the default copy that ships with gmStudio and will be used by the translator instead. of the default copy that ships with gmStudio.
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).
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.
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.
Be careful not to change the system default files when you are merging them into your project-specific files.