Translation Scripts

Overview

gmStudio makes extensive use of XML scripts to direct the translation process.

Translation Scripts

A Translation Script is a text file in XML format that contains a collection of migration commands.

Every migration task in your migration project can be assigned a different translation script template to direct its unique process, typically, all of the tasks in a migration project use the same template script.

One of the standard templates (Interoped-Externals Template for VB6 Migrations) is annotated below:

Sample Default Translation Script

<gmBasic>
<!-- create a storage area for the semantic model -->
 
<Storage Action="Create" Identifier="%JobId%" />
 
<!-- set translation options -->
 
<Select Progress="1" />
<Select DevEnv="%DevEnv%" />
<Select Dialect="%Dialect%" />
 
<!-- set directories for deployment and external assemblies -->
 
<Select DeployLocation="%NetProjFolder%" />
<Select Library="%InteropFolder%" />
 
<!-- set directories for IDF file and other config files -->
 
<select Target="%UserFolder%" />
<Select Local="%IdfFromCodeFolder%" />
<Select System="%IdfFromIdlFolder%" />
 
<!-- compile code and build initial semantic model -->
 
<Compile Project="%SrcPath%" />
 
<!-- analyse/transform semantic model -->
 
<Analyse />
 
<!-- set output file path and author target code -->
 
<Output Status="New" Filename="%BndPath%" />
 
<Author />
 
<!-- close and save the semantic model file -->
 
<Storage Action="Close" />
 
</gmBasic>

Translation Script Parameters

Before gmStudio runs the translation, it edits a number of parameter place holders in the script. The use of parameters generalizes the scripts for use with multiple migration units. These parameters are described in the table below:

Parameter	Description
%GenExternFolder%	Computed location of prototype assemblies
%MigName%	Migration Project Name
%JobId%	Unique Task Identifier
%Dialect%	Target .NET language ( csh \| vbn )
%JobName%	Simple Task Identifier
%SrcFileStem%	Migration Unit File Name without extension
%SrcPath%	Migration Unit File Path
%SrcFolder%	Migration Unit File Folder
%BndPath%	Migration Unit Bundle File Path
%NetProjFolder%	Migration Unit Deployment Folder
%DeployFolder%	Root Deployment Folder
%ProjFolder%	Migration Workspace Root Folder
%VirtualRoot%	Virtual Root
%UserFolder%	User Configuration Files Folder
%IdfFromCodeFolder%	IDF From Code Folder
%IdfFromIdlFolder% ,	IDF From IDL Folder
%InteropFolder%	Interop File Folder
%DevEnv% ,	Target .NET IDE ( e.g. VS2010 \| VS2012 )
%AppRoot%	Application Configuration Root Directory
%ResxFolder%	Resx Files Folder
%TranDate%	Time Stamp of the form MMDD-HHmm
%ReferenceList%	List of references statements for COM dependencies
%TranSettings%	When using Wizard Mode this parameter is replaced by gmPL commands based on the settings

Default Script Templates

gmStudio ships with four default Translation Script templates:

tran.vbp_std.xml: For VB6 Migrations using the Interoped Externals Strategy
tran.vbp_bld.xml: For VB6 Migrations using the Prototype Externals Strategy
tran.asp_std.xml: For ASP Migrations using the Interoped Externals Strategy
tran.asp_bld.xml: For ASP Migrations using the Prototype Externals Strategy

The standard templates are small XML files located in the [INSTALLDIR]\support\settings folder.

You may modify the standard templates or create your own.

The names of the default scripts are specified in the application config file.

TranVbpStdTemplate = "tran.vbp_std.xml"   ' Default translation VB6 template
TranAspStdTemplate = "tran.asp_std.xml"   ' Default translation ASP template

When you create a migration project, gmStudio creates a copy of the appropriate script template and places it in the workspace\usr folder. This copy will be associated with the migration tasks and used going forward.

You can change the script associated with a migration task by editing the TScript field on the task record.

Standard Script Templates Compared

As a brief introduction to Translation Scripting, let us compare these standard scripts.

VB6 Interop vs. VB6 Prototype

Comparing the following files:

tran.vbp_std.xml: For VB6 Migrations using the Interoped Externals Strategy
tran.vbp_bld.xml: For VB6 Migrations using the Prototype Externals Strategy

shows differences in three sections

1) Two Translation Options added to the prototype script.

<Select BuildFile="local" />

BuildFile="on" tells the translator to generate stub classes for all external COM components.

2) The Library setting is different.

INTEROP <Select Library="%InteropFolder%" /> ---PROTOTYPE <Select Library="%GenExternFolder%" />

The Library setting tells gmBasic how to author HintPath settings in the target projects.

3) Two registry commands are added to the prototype script.

<Registry Type="idfstatus" Source="stdole2.tlb" Target="migrate" /><Registry Type="idfstatus" Source="MSVBVM60_3.dll" Target="migrate" />

Stdole and VBRUN are special cases of COM libraries that are rarely needed even though they explicitly show up as references in VBPs files. These two commands tell gmBasic to suppress generating and referencing the prototype assemblies.

VB6 Interop vs. ASP Interop

Comparing the following files:

tran.vbp_std.xml: For VB6 Migrations using the Interoped Externals Strategy
tran.asp_std.xml: For ASP Migrations using the Interoped Externals Strategy
shows differences in seven sections.

1) The DeployLocation for a website unit is computed differently than for a VB6 unit.

VB6 <Select DeployLocation="%NetProjFolder%" />
---
ASP <select DeployLocation="%DeployFolder%" />

2) The Virtual Root is needed for website processing so a select to set it is added

<select VirtualRoot ="%VirtualRoot%" />

3) Web Application Project Files require special GUIDS to get along with Visual Studio. They are set using these registry commands in the ASP script.

<if lang="csh">
   <Registry type="guid" source="Project" target="{7EE74E01-07B7-4C4F-B053-895BB67A3A51}" />
   <Registry type="guid" source="ProjectType1" target="{349C5851-65DF-11DA-9384-00065B846F21}" />
   <Registry type="guid" source="ProjectType2" target="{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}" />
   <Registry type="guid" source="Flavor" target="{349C5851-65DF-11DA-9384-00065B846F21}" />
</if>
<if lang="vbn">
   <Registry type="guid" source="Project" target="{CE8BB43C-9A4F-4900-AFD0-A4C18D1C30B1}" />
   <Registry type="guid" source="ProjectType1" target="{349C5851-65DF-11DA-9384-00065B846F21}" />
   <Registry type="guid" source="ProjectType2" target="{F184B08F-C81C-45F6-A57F-5ABD9991F28F}" />
   <Registry type="guid" source="Flavor" target="{349C5851-65DF-11DA-9384-00065B846F21}" />
</if>

4) Websites do not explicitly declare all of their COM dependencies; so, the dependencies must be determined by analyzing the site. Once this is done the references can be inserted by gmStudio or by hand. The place holder in the ASP template facilitates this.

%ReferenceList%

5) It is somewhat common that ProgIds in CreateObject statements use non-standard naming conventions. The file Registry.xml helps gmBasic resolve non-standard ProgIds used by various third party components.

<Include Filename="%AppRoot%\support\lang\registry.xml"/>

6) Slightly different compilation commands are used for VB6 and ASP.

VB6 <Compile Project="%SrcPath%" />
---
ASP <Compile PageSlice="%SrcPath%" />

7) A name for the web application project and its default namespace must be explicitly provided to gmBasic since it cannot be determined from the source code. This is done using the name attribute of the Author command.

VB6 <Author />
---
ASP <Author name="%MigName%" />