The gmAPI Paradigm
The paradigm for using gmAPI with gmStudio is a bit different and is engaged by setting the TScript field on a gmProj Task to the path of a .NET Exe rather than an xml file.
- gmPL: gmStudio prepares an actual translation script (JobID.xml) by detokenizing %placeholders% and merging ScriptRules found in the template translation script file specified by the Tscript field for each task in the gmProj file.
gmStudio spawns gmBasic.exe passing the actual translation script as a command line argument. gmBasic.exe executes the gmPL commands specified in the actual translation script. - gmAPI: gmStudio prepares a task information file (JobID.xml) .
gmStudio spawns your gmAPI Exe (e.g. Upgrade.exe) passing the task information file as a command line argument. Upgrade.exe uses the TaskInfo, ScriptRules , and gmslLibrary APIs as needed to invoke gmBasic services.
The use of ScriptRules file(s) are optional in the gmPL approach because a developer may insert custom XML commands (i.e. Select, Registry, Fix, Refactor) into the template translation script manually. However, since there are no translation scripts with the gmAPI approach, ScriptRules are typically required to integrate XML.
The gmslAPI.dll integrates gmAPI, TaskInfo, and ScriptRules APIs into one assembly. The assembly depends on the Service Command Model Operations DLL (SCMoperations.dll) for implementation of gmBasic services. SCMoperations.dll is a Win32 DLL requiring you build your gmAPI executable with Platform=x86.
gmAPI is built on Managed-Native integration. The implementation of gmBasic services that power gmAPI services were developed to work in the gmBasic.exe console application and some behavior may be non-intuitive. We are working on improvements to this API to make it more a natural fit for custom managed EXEs.
See also
gmAPI reference and samples are here: gmAPIIntroduction
Overview
Content Tools