The .NET languages and runtime environment are very different from VB6, for example with 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 MigrationSupport 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.
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.