...

1. Clean Translation Results
   
   By "Clean" we mean no errors reported during the translation process.  Translation errors occur due to missing or mis-referenced code, missing COM descriptions or other environmental issues, or by unexpected code.  If any errors are reported, they should be addressed before proceeding.
    

2. Local (Stand-Alone) Build-Complete Results 
   
   The Local Build is a simplified build model where the resulting projects are stand-alone.  They are independent of each other even if they were cross referential in the legacy codebase.   Legacy references to COM components are replaced by references to COM files within the projects as a project-specific local "Stub Framework" .
     

   Image RemovedImage Added

3. Global (Integrated) Build-Complete Results
   
   The Global Build is an integrated build model where the resulting projects reference  each another.  Generally speaking, external references in the legacy projects are reproduced as external references in the new projects.  Legacy references to COM components are replaced by references to a set of generated "COM Stub Framework" assemblies.  The Stub Framework is all .NET code, but it exposes the interfaces needed to allow building the upgraded legacy projects.
   

   Image Removed

   
   

   Image Added

The scripts for first two steps are setup more or less automatically and can normally be handled with various translation tuning techniques in a single upgrade script template. The third step requires a special type of script called a Global Stubs script.   This document describes the concepts and activities required to setup and run a GlobalStubs script and then use its output in your upgraded system to produce your Global Build.

...

Here is an screen shot of gmStudio holding a solution that generates and integrated upgrade solution for a enterprise application comprised of 17 inter-related VBPs.  

Image Added

Notice that the translations for the "Standalone" translations are larger because they contain the generated stub framework as embedded files rather than referencing the consolidated stub framework as external assemblies.

...

The main purpose of the Standard Upgrade to generate initial translations and the COM Stub Framework projects and assemblies that set the a solid foundation for adding Custom Upgrade features such as  Custom COM Replacement , dead code cleanup, integrating new code, etc.  There are many types of potential Custom Upgrade requirements and many different ways to implement them with the help of gmStudio.  See this article for a discussion of Scoping and Planning a Custom Upgrade and See our Upgrade Samples for examples of how custom upgrades may be implemented using gmStudio.  Please feel free to contact us to discuss your specific requirements.Image Removed 

...

Step-by-Step Global Stubs Process

...

NOTE: these are very close the buildFile=local scripts with a few changes. Of course the big one is this:

<Select BuildFile="local" />

...

---

...

<Select BuildFile="global" />

I also change Library; I set it to deployFolder to simplify project-cross-references and linking to the stub framework.

<Select Library="%DeployFolder%" />

Finally the Select.Local is modified so that FromCode IDF files generated for BuildFile=local translations are separate from the ones generated for BuildFile=global translations. This is a best practice if you are running multiple translations in the same workspace. 

 <Select Local="%ProjFolder%\idf\%TaskTag%" />

Create a ScriptRule to conditionally author either local or global stubbing commands:

FILE: usr\StandardUpgrade.Rules.xml
<ScriptRule id="SupportFramework">
<!--
Support Framework Conventions
-->
<Option Condition="'%TaskTag%'=='std'">
   <Select BuildFile="local"/>
   <Select Library="%RuntimeFolder%" />
   <Select Local="%ProjFolder%\idf\%TaskTag%" />
 </Option>
<Option Condition="'%TaskTag%'!='std'">
   <Select BuildFile="global"/>
   <Select Library="%DeployFolder%" />
   <Select Local="%ProjFolder%\idf\%TaskTag%" />
  </Option>
</ScriptRule>
...

Reference the SupportFramework rule in the template translation script. This ScriptRule 
element may replace the BuildFile and Library commands normally placed in the file.

FILE: MigName.std.Tran.xml
<!-- Translation options -->
<Select GlobalSettings="%UserFolder%\GlobalSettings.xml" />
<Select Progress="1" />
<Select DevEnv="%DevEnv%" />
<Select Dialect="%Dialect%" />
<Select OptionalArguments="on" />
<Select DeployLocation="%NetProjFolder%" />
<Registry type="GUID" source="Project" target="{%TaskGuid%}"/>   
<ScriptRule id="SupportFramework" FileName="..\usr\StandardUpgrade.Rules.xml" /> <--- add this

...

This will generated, deploy, and build the application translations.

8) Generate a VisualStudio Visual Studio solution to reference your integrated projects

...