This section describes the rational for gmStudio's approach to deployment .
| Table of Contents |
|---|
Why Bundle?
One of the unique features of gmStudio is that is allows you to separate code generation from code deployment. This best practice resulted from our work in helping teams perform migrations of very large systems. It works like this: rather than publishing the translated code as separate files and folders immediately as they are produced, gmStudio creates a consolidated text archive that contain all the files. This text archive, or bundle file as we call it, must be explicitly processed, or "deployed", to create the separate files and folders. By default, this feature works behind the scenes and it is extremely fast so you barely notice it. This approach provides additional control and visibility to the migration effort, and having all the generated code in a single file facilitates several useful operations:
...
- First, different operating systems use different internal file formats for text files, which form the bulk of the files in the site. This system knows these formats and can both recognize and produce them as it performs the various deployment operations. Binary zip formats cannot change the formats as they gather and then distribute files; thus, the user is required to use a separate process to do the text-line format conversions.
- Second, the authoring facilities of this system produce outputs which contain many files. It makes this operation easier to manage if the authors can produce single files using this text-based format that can then deployed once they have been produced and accepted.
...
What is a Bundle File?
Bundle files are the self-extracting text archives produced by the translation process.
...
The translator always writes your translation to a bundle file that you specify in the Translation Script and a separate step, running the deployment tool -- is used to run the bundle file. By default, gmStudio handles all of this behind the scenes.
Viewing and Reporting your Bundles
You can view the deployment logs for a given migration unit by selecting the [Deploy Log] option on the [Task Details] tab. Checking the [Grid] option here will display the internal contents of the bundle file.
You can generate a report of the internal contents of the bundle files for selected migration units in your project by clicking [Reports/Code Bundles].
How Deployment Works
Deployment is a specific step in the migration process that can be turned on of off from the [Batch Control] Form. By default deployment is always on and runs after the Translation step and before the Build step.
...
ShellToolExe = "%SystemFolder%\deploy.exe"
' the 'deploy' sub-command passed to the Shelltool will run shell commands such as rmdir/mkdir/execute otherwise only the cat commands run.
DeployCmd = "cmd.exe /C pushd '%LogFolder%' && '%ShellToolExe%' '%BndPath%' verbose replace > '%LogPath%' 2>&1 %UserCmd% && popd"
%LogFolder% is the workspace\log folder where gmStudio does almost all
of its batch operations
%ShellToolExe% is the path to deploy.exe
%BndPath% is the path to the code bundle to be processed
verbose is a command line flag that tells deploy.exe to report progress
replace is a command line flag that tells deploy.exe to replace files
with the ones in the bundle.
%Logpath% is a file that will capture the deployment log
%UserCmd% is a place-holder for a user batch command script
| Warning |
|---|
| ||
By default, the deployment step will replace files in the deploy folder. If you have made hand changes to the code in that folder and have not captured those changes in the tool configuration |
The deploy tool is actually a command processor that can remove and create folders, and execute external programs. For example, the deploy.exe utility is used to deploy and build to binary (by running MSBuild) all the prototype assemblies generated in a prototype translation.
...
or saved a backup in another folder, your changes will be overwritten by the next deployment. |
The deploy tool is actually a command processor that can remove and create folders, and execute external programs. For example, the deploy.exe utility is used to deploy and build to binary (by running MSBuild) all the prototype assemblies generated in a prototype translation.
Performing a Deployment with gmStudio
Deployment is a standard operation in the batch upgrade process, however if you want to deploy your migration files on demand, perform the following steps:
- Select [Open .NET Project Folder] on the migration unit context menu open the deployment folder for that unit.
- Select [View\Deploy Folder] to open the deploy folder for your migration project.
Default VB6 Deployment
Translating a VB6 migration unit produces a set of files that correspond to the ones referenced by the source VBP:
...
[WorkspaceRoot]\[MigName]\deploy\[TaskName]_[TaskTag]_[Lang]
where:
[WorkspaceRoot] is the workspace root folder
[MigName] is the migration project name
[TaskName] is the original VBP file
[TaskTag] is the task tag assigned to the task when it was added
[Lang] is 'csh' or 'vbn' if the target language is C# or VB.Net respectively.
...
Select [Open .NET Project Folder] on the migration unit context menu open the deployment folder for that unit.
Select [View\Deploy Folder] to open the deploy folder for your migration project.
Example
The Interop2_csh.gmproj sample has the following settings
...
Example VB6 Deployment
The ScanTool sample has the following settings
In the project file header: ProjFolder = "C:\GMS\samples\workspace\DemoScanTool" DeployFolder = "%ProjFolder%\deploy" On the task records: TaskTag = "iop2mgd" Lang = "csh" SrcName = "ScanToolUI" or "ScanToolLib"
The Thus, the full path to the csproj files produced for each migration unit is:
- C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolUI_iop2mgd_csh\ScanToolUI.csproj]
- C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2mgd_csh\ScanToolLib.csproj]
gmStudio communicates the deployment folder to the translation process using a select DeployLocationDeployLocation command in the Translation Script. For example the tran.Interop2_csh.xml script template contains the following statement
<Select DeployLocation ="%NetProjFolder%" />
gmStudio uses information in the Configuration Files to set %NetProjFolder% to the correct value when you run the translation.
...
The contents of the file look like this:
deploy V9.77 (BETA.007) System Build(6/18/09 8:40:51) Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolUIScanToolLib_iop2_csh" /> OR <Select DeployLocation ="\ScanToolLib.csproj Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\AssemblyInfo.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\modScanToolLib.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh" />
This ultimately ends up in the bundle file and directs the physical deployment of files to disk. Deploying a bundle file produces a log file. In the case of this example, the path of the log is
...
\clsVBPRefReporter.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\
...
deploy\
...
ScanToolLib_
...
iop2...
_csh
...
The contents of the file look like this:
deploy V9.77 (BETA.007) System Build(6/18/09 8:40:51) Unbundling:\clsDirList.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\ScanToolLibclsVBPBinReporter.csprojcs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\AssemblyInfoclsCOMReporter.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\modScanToolLibclsVBPModReporter.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\clsVBPRefReporterclsVBPCntReporter.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\clsDirListclsVBPSrcReporter.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\clsVBPBinReporter.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\clsCOMReporter.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\clsVBPModReporter.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\clsVBPCntReporter.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\clsVBPSrcReporter.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\clsScanControl.cs
Default Web Deployment
Translating a web site has a different deployment model because folder structures tend to be much more elaborate and important to the conceptual design, security, and operation of the site. In addition #include paths may be virtual or physical and the concept of a virtual root directory comes into play.
The discussion here refers to a web site migration script that contains commands to compile all the pages in the site, but it would also apply to a script for a single page.
Translating a web site produces a set of files that correspond to the ones referenced by page slices named that script as follows:
...
clsScanControl.cs
Default Web Deployment
Translating a web site has a different deployment model because folder structures tend to be much more elaborate and important to the conceptual design, security, and operation of the site. In addition #include paths may be virtual or physical and the concept of a virtual root directory comes into play.
The discussion here refers to a web site migration script that contains commands to compile all the pages in the site, but it would also apply to a script for a single page.
Translating a web site produces a set of files that correspond to the ones referenced by page slices named that script as follows:
- A Web Application Project for the entire site. The name of this file is the same as migration project file with a .csproj or .vbproj extension. This project names and relates all the .NET files generated for the site.
- A default Web.Config file
- A collection of .aspx files corresponding to the asp pages. These files have the same names and relative locations as the original asp pages. These files contain the "Markup" part of each .NET page class.
- A collection of .aspx files corresponding to the asp pages. These files have the same names and relative locations as the original asp pages. These files contain the "MarkupCodeBehind" part of each .NET page class.
- A collection of .aspx files corresponding to the asp pages. These files have the same names and relative locations as the original asp pages. These files contain the "CodeBehind" part of each .NET page class. A collection of .ascx ascx files corresponding to the include files. These files have the same names and relative locations as the original include files. These files contain the "Markup" part of each .NET control class.
- A collection of .aspx files corresponding to the include files. These files have the same names and relative locations as the original include files pages. These files contain the "CodeBehind" part of each .NET control class.
By default, all files generated for the site are placed in a folder hierarchy that corresponds to the source folder hierarchy, but under the deployment folder. The deployment folder for a web translation is similar to the one used for a VB6 translation. The default folder for a migrated web site uses the following naming conventions:
[WorkspaceRoot]\[MigName]\deploy\
where:
[WorkspaceRoot] is the workspace root folder
[MigName] is the migration project name
...
By default, all files generated for the site are placed in a folder hierarchy that corresponds to the source folder hierarchy, but under the deployment folder. The deployment folder for a web translation is similar to the one used for a VB6 translation. The default folder for a migrated web site uses the following naming conventions:
[WorkspaceRoot]\[MigName]\deploy\
where:
[WorkspaceRoot] is the workspace root folder
[MigName] is the migration project name
| Tip | ||
|---|---|---|
Where are my ASPX files?Not getting anything except empty project files from your web site translation? gmStudio probably failed the deployment step because of missing sub-directories in the \[workspace]\deploy folder. Look at the deploy log and you will probably see error messages to that effect. This is a common mistake with ASP migrations because by default setting up the ASPX site directory is a manual preparation step. What we normally do is create a full empty folder tree in the deployment root using a tool like robocopy. Of course web sites depend on many types of "pulp" files (images, css, etc.) that will also be needed to run and test the new site so you may want to copy those as well. Again robocopy is good for setting up the "test site" directory from your current site directory. For ASP upgrades, you will typically associate a user batch script with the migration tasks and modify that script with the following commands:
These pre-deployment commands create empty folders to receive the generated site and also delete all files from prior translations. |
Example Web Deployment
The DemoFMSWeb_csh.gmproj sample has the following settings:
...
This folder ultimately ends up in the bundle file and directs the physical deployment of files to disk.
Custom VBP deployment
The VBP deployment conventions are controlled by several settings in the gmStudio.cfg file:
...