This section describes how gmStudio can help a migration team assess, plan, prioritize, and prepare for a migration effort.
Migration Environment -- Hardware
One of the first steps in preparing for a migration effort is to provision a reliable, high-performance development workstation that you will use to perform migration work. This is typically one of the workstations you are already using to maintain and build the source codebase.
In terms of disk, CPU and memory, this machine should be sized for .NET development using Visual Studio -- the bigger the better.
Migration Environment -- Software
Once you have a migration workstation, install gmStudio and external tools as outlined on the Overview/Installation page.
Migration Environment -- Source Codebase
In addition to hardware and software, your migration environment must contain a complete, internally-consistent and properly configured copy of your source codebase. A codebase has two parts:
Full System Build
A good way to validate your migration environment and source codebase is to perform a "full system build". Specifically, you should be able to successfully build your entire VB6 codebase on the migration workstation.
Validation is a bit trickier for ASP sites since there is no way to do an automated build test. Technically speaking, you would have to request and verify every page to even begin to check all of the ASP code.
Fortunately, gmStudio includes several facilities to validate source codebases, both VB6 and ASP, as discussed in the Verification section. Also, the gmBasic translator is a strict compiler that can detect problems with your code that VB6 and ASP may not.
Migration project files specify which legacy components to migrate and how to migrate them. A migration project can be created using the [Migration Project Setup] form. You can access the [Migration Project Setup] form in two ways:
After adding migration units to your migration project, you will use the Build Order tool to sort them in build order (aka dependency-first order)
The results of the Build Order tool depend on the type of your migration project:
The [Tools/Set Build Order] option will compute the Build Order and re-arrange the Migration Units of a Migration Project in ascending order of dependency to other units in the project. As a result, units that do not depend on other units in the project will be migrated first and units that do depend on other units will be migrated later.
Setting the Build Order is one of the default processing steps for all new migrations.
gmStudio uses information about COM components so it can recognize and interpret them correctly during the translation process. For efficiency, gmStudio stores this information in XML files. These files are called Interface Description Files (IDFs) and they must be created before translating any codes that depend on the components they describe.
The [Tools/Author Interface Descriptions] option will create IDFs for your migration project.
This creating interface description files is one of the default processing steps for all new migrations.
If you selected Externals=Interop when you setup your migration project, the system will create Interop assemblies for the external COM components referenced by your codes.
The [Tools/Author Interop Assemblies] option will create Interop assemblies for your migration project.
Creating interop assemblies is one of the default processing steps for "Interop" migrations.
Default Interop Assembly Location
You can easily alter this default behavior by changing the configuration of the translation process. Ultimately it is a moot point as gmStudio allows you to configure the translator to produce codes that do not use interop.
If you selected Externals=Prototype when you setup your migration project, the system will create prototype assemblies for the external COM components referenced by your codes.
The [Tools/Create BuildSet] option will create prototype assemblies for your migration project.
Create A BuildSet is one of the default processing steps for "prototype" migrations.
.NET Windows Forms applications use Resx files to store metadata for each form. Resx files contain information used by the forms designer as well as graphics (i.e., bitmaps, icons) and other binary content such as control property settings and binary information needed for Interoped controls (i.e., OCXState).
You will need Resx files in order to maintain your user interface components with the .NET designer and to display .NET user interfaces at runtime.
The [Tools/Author Resx Files] option will create Resx files for your migration project.
Create Resx files is not a default processing steps for new migrations.
By default, the object of each Translation Script is a single migration unit, a VBP or an ASP page, and processing that script produces a single .NET project as output. This one-legacy-project-to-one-.Net-project model is appropriate for VBPs. However, when migrating a web site, you may want to produce a web application project for the entire site. As described here, gmStudio has procedures for doing this. Prepare Web Site Script Page