Utility Reports

Overview

Utility reports provide auditing and code generation facilities for the gmStudio application:

Migration Project List

The gmProj file settings, parsed, tabulated, and aggregated. What settings are in my gmproj files?

MigName        ' Migration Project Name
MigType        ' Migration Project Type
DevEnv         ' Target .NET Development Environment
ProjFolder     ' workspace root folder
DeployFolder   ' deployment root folder
VirtualRoot    ' virtual root folder
TlbSearchPaths ' type  library search paths
JobFilter      ' task filter string
CmdList        ' batch command list

Multi-Unit Script

The Multi-Unit Script report is used for preparing a baseline Translation Script for a web site translation task. Beware that running this report also adds a task that references the multi-unit script to your migration project. You will have to edit the script before you run the full site translation. Additional details on ASP migration can be found in the Preparation section.

GlobalStub Script

VB6/ASP/COM systems typically depend on one or more COM APIs that provide platform services such as database access, file system access, XML handling, UI controls, etc. When upgrading an application to a new platform, the way the application requests and consumes platform services must change. This is a very important consideration for VB6/ASP/COM to .NET upgrade work since each COM API requires an effective upgrade strategy.

In the early stages of an upgrade project, the upgrade strategies for COM APIs may not yet be certain. To prevent this uncertainty from blocking initial upgrade work, gmStudio helps teams generate a .NET stub framework to satisfy COM dependencies. This stub framework may be used for the initial builds of the .NET code.

The <Select BuildFile="option" /> command controls how the COM framework is generated and linked to upgraded application projects.  A typical upgrade project proceeds from BuildFile=local, to BuildFile=global, to BuildFile=off as COM replacement  strategies are resolved and implemented. 

• When BuildFile=local, the COM dependencies are satisfied by COM stub files. These files are specific to each application project and are deployed with and referenced directly by each project. 
• When BuildFile=global, the COM dependencies are satisfied by separate COM stub assemblies.  A stub assembly is generated for each COM API and contains the API needed to satisfy the combined dependencies of a set of .NET application projects. Using BuildFile=global is a requirement for upgrading multiple inter-related projects that share COM dependencies. These dependencies must be satisfied by a consolidated set of assemblies rather than by separate files embedded in the individual .NET projects. 
• Finally, when BuildFile=off, the COM dependencies are satisfied by separate assemblies as defined by the user, possibly interop assemblies, or other pre-existing assemblies, such as third-party .NET APIs. 

The report generates a GlobalStubs script for the selected upgrade tasks (VBPs) and adds it to your project.  The script tells gmBasic to, analyze COM dependencies across a set of upgraded projects and generate the code for the COM stub assembly projects that will satisfy those dependencies. The generated file will also contain the .NET build commands needed to  compile the stub assembly projects.  

See also this article on the Global Stubs concepts and how this report fits in.

Target Code Scan 

The results of searching the generated units for user-defined lists of regex patterns.  The list of patterns to search for is in CodeScanList.txt file.  See Search Panel

SrcName ' Migration Unit Name
RunDate ' Semantic Model Creation Date
RecType ' Report Type = "SCAN"
MemName ' Search Pattern
MemClas ' Matching File Name
MemLibr ' Matching Migration Unit Name
MemType ' Matching File Type
Pos_Cnt ' Matching Location (line number)
LocText ' Matching Text Line
LocMemb ' Matching Member
LocFile ' Matching File Path
LocName ' Matching File Name
LocType ' Matching File Type

Target Code Changes

The results of comparing the latest bundle file with latest bundle file snapshot.  The actual comparison is done based on the command line specified by the DiffToFileCmd setting in the gmStudio.cfg fle. Running this report also updates LastMsg field for each selected task.

Generate Visual Studio Solution 

Produces a Visual Studio Solution file for all of the .NET projects in your  deploy folder or based on a GenerateSolution.txt file. 

1) The SLN file is named MigName.sln and saved in the workspace deploy folder.  Alternatively, it will use a X_GenerateSolution.txt where X.gmProj is the name of your gmProj file.  The X_GenerateSolution.txt takes precedence over MigName_GenerateSolution.txt file.

2) The SLN file organizes all the C# and/or VB.NET projects in the deploy folder.  Any projects you in the deploy folder will be included as long as their language matches the migration project target language.  If you wish to generate a mixed language solution with both VB.NET and C# projects, you must set AllowMultiLangSln in the gmStudio application settings file.

3) The project files are modified so that assembly references are replaced with project file references.  In order to take advantage of this, you must configure gmStudio to set the project GUID in each .NET project file using a Registry command in your translation script.  See the fmStocks sample for an example of how this is done.

4) The process also generates a GenerateSolution.txt file in the workspace User Folder if one does not already exist. 

If present, this file will lists control the content of the Solution . Note, the first project in the list will become the startup project unless you have already specified a different project using Visual Studio.

%DeployFolder%\Project1\Project1.csproj
%DeployFolder%\Project1\Project2.csproj
%ProjFolder%\usr\runtime\MigrationSupport\MigrationSupport.csproj

Optionally, you may add Folders to your solution by adding [Folder] records as illustrated below.  Only one level of nesting is supported.

[Folder] App
	%DeployFolder%\ScanToolLib\ScanToolLib.csproj
	%DeployFolder%\ScanToolUI\ScanToolUI.csproj
[Folder] Support
	C:\gmTestBed\ScanTool\proj_csh\usr\runtime\TLI\TLI_csh\TLI_csh.csproj
    C:\gmTools\gmRuntime\MigrationSupport\MigrationSupport\MigrationSupport.csproj

You may also add additional levels of subfolders using backslash in the folder names for example:

Sample GenerateSolution.txt file with Nested Folders
[Folder] App\Lib %DeployFolder%\ScanToolLib\ScanToolLib.csproj [Folder] App\UI %DeployFolder%\ScanToolUI\ScanToolUI.csproj [Folder] Support\TLI C:\gmUtils\gmRTL\COM\TLI\gmRTL.TLI.csproj [Folder] Support\Core C:\gmUtils\gmRTL\gmRTL\gmRTL.csproj

You may edit this file to add or remove projects that will be in the solution. 

If this file is not present, gmStudio will create one listing all of the .NET projects in your  deploy folder.

You may edit the Project List file be clicking [Edit Project List File] item from the Tools Menu.

This Visual Studio Solution generation feature also be initiated in two other ways:

1) as a step in the Batch List batch control menu.  The SLN file is opened in Visual Studio if you initiate it from the Reports menu.

2) by clicking the [Generate and Open VS Solution] item from Tools menu.

AltSlnBuilderCmd = "cmd.exe /C pushd '%LogFolder%' && '..\gmTranslate\gmBin\gmTools.exe' sln -g '%GmProjPath%'> '%LogPath%' 2>&1 && popd"

Pre-Processed Source

This report generates a bundle file (see Deployment) containing a content for a version of the VB6 source that has had some early stage pre-processing (e.g. Compile/Fix) applied by the tool.  This may be useful if you have a conditional VB6 code (i.e using a lot of #if/#else) and you wish to simplify the analysis and upgrade project by working with a particular non-conditional variant of that code.

You may use the deployment tool to publish the pre-processed source files into a SrcPrep folder next to the source root folder, for example:

"\Program Files (x86)\GreatMigrations\gmStudio\support\tools\Deploy.exe" WPFCalculator-PrepSource.bnd deploy verbose replace

Generate Project Signature

A project signature is information that identifies the unique set of files in your project and the total, non-blank lines of code in those files. This report generates a file containing a Project Signature for the selected migration tasks.  A project-signature file may be used for perpetual, project-specific licensing.  Contact us for more information on Project-specific licensing if our standard time-limited licensing does not meet your needs.