The .NET languages and runtime environment are very different from VB6; for example, VB6 and .NET differ in regards to critical details like null handling, variants, type conversions, date and time variables, color variables, string indexing, object lifetime, and the various services provided by intrinsic functions and objects. A migration support library helps a code designed to run in VB6 work correctly when it is re-implemented for .NET. However, using a migration support library is an option, not a requirement. If you decide to not use a migration support library, you will usually have to rework some of the application code to fit the runtime conventions of the .NET platform. The amount of work required to do this depends on how the legacy code uses VB6 language features and how you intend to make changes for .NET.
During the early stages of an upgrade project, you have the option to have gmStudio generate a stubbed-out version of the support library and integrate it with your project(s). This is similar to the stub classes that can be generated for COM APIs used by your code. Depending on the rules in your upgrade solution, the generated stub codes may be replaced by our sample implementation or replaced by something else altogether.
Historically, the RTL namespace conventions employed by gmStudio were simple: almost all support functions were implemented in a single MigrationSupport.Utils static class. The idea was to keep it simple and easy to describe: references to these functions were expected to be temporary placeholders until alternative, custom translations were designed and implemented by the Upgrade Team as part of their Upgrade Solution. However, we have found that some teams are not able to complete the analysis and design work needed for a full custom upgrade; they are comfortable with using the RTL we provide out-of-the-box. Furthermore, the RTL has grown over time, the MigrationSupport.Utils class has become bloated. We now find that a more structured RTL model is needed to organize the RTL services. To better meet this need, we are enhancing our RTL specification to allow stubbing and using a more structured set of namespaces and classes. The intent is to provide a slightly more granular RTL framework that is more descriptive and maintainable. We are calling these new conventions gmRTL.
The gmRTL namespace and class structure conventions replaced the legacy conventions in the 2021-11-30 release and the legacy conventions (i.e. MigrationSupport, MigrationSupportUI, etc.) were deprecated.
Read more in this article.
Here are some key points about our runtime library:
Using our Runtime Library is NOT a requirement.
Many teams prefer to minimize dependencies on third-party components. These teams may configure gmStudio to rewrite their applications to use .NET directly or to use a their own runtime support framework(s).
In our standard methodology, the initial translations do not reference a runtime assembly at all. Instead, gmStudio generates stub classes to satisfy some VB6/COM platform dependencies and integrates the stub classes with code generated from the legacy source. In subsequent phases of the methodology, gmStudio may be configured to automatically replace VB6/COM dependencies with .NET APIs of your choice.