...
Every migration task in your migration project can be assigned a different translation script template to direct its unique process, typically. Typically, all of the tasks in a migration project use the same template script.
...
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 ... VS2019 ) |
| %AppRoot% | Application Configuration Root Directory |
| %ResxFolder% | Resx Files Folder |
| %TranDate% | Sortable Time Stamp of the form |
YYYY/MM/DD-hh:mm:ss | |
| %ReferenceList% | List of references statements for COM dependencies |
| %TranSettings% | When using Wizard Mode this parameter is replaced by gmPL commands based on the settings |
| %LN% | Line Pragma. Expands to the string =@ScriptFilePath@LineNumber@. Typically used with translation log report for location of replace commands. This may be used with Translation Log Grid view for script maintenance. |
Default Script Templates
gmStudio ships with four default Translation Script templates:
...
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.
...
COM Interop vs.
...
COM Stub Prototypes
Comparing the following files:
...
1) Two Translation Options added to the prototype script.
<Select BuildFile="local" />
BuildFile="onlocal" tells the translator to generate stub classes files for all external COM components.
ImportsGlobal="on" tells the translator to accumulate external dependencies across all migration units so the consolidated set of external members will be available in a single set of prototype assembliesCOM API references.
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.
| Code Block | ||
|---|---|---|
| ||
<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) Unlike VBP files, 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 %ReferenceList% place holder in the ASP template facilitates this.
<!-- PLACE COM REFERENCES HERE -->
%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%" />
Preparing an ASP solution
1) Prepare to do the first translation: generate IDFS, setup registry-libname, etc.
2) Work through the pages one at a time: add registry-fixtype and PostEdits to the Page Template Script, and compile refactors and fixes to GlobalSettings.xml. You may also develop cross-page artifacts such as custom IDFs, refactor files, and script includes. Step 2 produces the solo page solution: a Page Template Script and supporting files that can be used to generated the "one page site" for each page that builds.
For ASP, PreEdits and Compile\Refactors are mainly done at the file level in usr\GlobalSettings.xml PostEdits are added to the Author block in the template -- unfortunately this means that all of Page Actual Scripts contain PosdtEdits all pages, not ideal, but generally not harmful. Also, for ASP, many of the PostEdits will apply to many of the pages, so "all for all" is probably more appropriate than trying to minimize the set of PostEdits for each page.
3) Generate the Site Template Script from the Page Template Script (Report\Utilities\Multi-Unit Script) in theory the only difference is that the Site Template Script has Compile PageSlices for all pages explicitly while the Page Template Script has just one parameterized Compile, <Compile PageSlice="%SrcPath%">.
4) Work through any Site translations issues and make adjustments to the Site Template Script until the web application for the entire site builds.