Intro
Prior to V40.14 language , gmBasic used the MigrationSupport namespace and class conventions for stubbing the language runtime support (RTS) framework. These conventions were found in the translation of application code referencing the RTS as well as the stub framework generated to satisfy the references.
MigrationSupport conventions had the following features:
- The namespaces of the language runtime support stub framework are hard-coded into the system and included MigrationSupport, MigrationSupportUI, and VB6Controls.
- Extension Extension method stubs are placed in the MigrationSupport.SystemExtensions class.
- Stub framework references are identified by scanning the generated code for the string "MigrationSupport" and also scanning the operation streams for references to status="extension" operations.
- MigrationSupport conventions are deprecated.
Beginning with gmBasic V40.1418, gmBasic system uses the gmRTL conventions for stubbing the language runtime support framework. gmRTL conventions have the following features:
- The namespaces of the language runtime support stub framework are driven by the metalang files. The default RTS namespaces include gmRTL.Core, gmRTL.GUI, and gmRTL.ASP.
- Extension method stubs may be placed in any namespace. The stubs for status=extensions extension methods are placed in a SystemExtensions class in the namespace specified by the Select.ExtensionMethods select. By default this namespace is set in VB7Lang.xml <Select ExtensionMethods="gmRTL.Core" />
- The gmRTL framework has more classes than MigrationSupport framework providing a more descriptive structure for organizing the framework members.
- Stub framework references are identified by details in the metalang and by scanning the generated code scanning the operation streams for references to RTS namespaces and classes.
- gmRTL conventions should be used for all new projects started after the 2021-11-30 release.
Note: stubs for references to COM APIs are handled differently from stubs for references to language operations. COM stub declarations are driven by COM IDFs and based on scanning operation streams for references to COM API elements. Also note that using the use of a stub framework is one possible mode of translation. It is typically used only in the early stages of an upgrade project before custom migration requirements are defined. Custom requirements may be implemented as custom migration rules that direct an automated translation meeting the custom requirements. See the Incremental Upgrade Cookbook for details.
Impact
Implementing the gmRTL conventions required numerous changes to the metalang and the gmBasic logic. The resulting RTS stubbing process is more precise , faster, and flexible . Furthermore, gmRTL as well as being a bit faster. gmRTL translations look very different from MigrationSupport translations, but the changes are refactoring: mainly changing different names for the namespaces and classes holding the RTS members. Although the organization and structure of the RTL stub framework changeschanged, the locations of RTS references in generated code is are the same.
Backward compatibility
Although the internal implementation and details of gmRTL language mappings are differ considerably different from MigrationSupport mappings, it is possible to reproduce MigrationSupport-style translations if you apply with custom migration rules. The The use and structure of the RTS framework in a translation is completely controlled by the tool's metalang files, so an upgrade team may implement a custom metalang to produce other translations. However, a simpler technique is to use a few refactoring and post-editing commands. The ScriptRules file below is an example of how to revert gmRTL translations back to MigrationSupport conventions if you must complete a project using the deprecated MigrationSupport.dll assembly.
...