Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

« Previous Version 5 Next »

Source code may contain bugs and ambiguities that go un-noticed on the classic platform, but interfere with the upgrade process.  We typically refer to this as "bad code" and it must be addressed in order get better translations. 

 "Bad Code" is a problem with both ASP and VB6, but it is more common in ASP because the ASP classic processor is not a true compiler.  The only ASP code that is ever formally checked by the ASP processor is the code that is actually executed by actual page requests.  ASP can have functions that are completely invalid and if they are not called, you would never know about it.  When we are translating a site, all the code on all the specified pages and their includes is compiled.  It is not uncommon for hidden problems in the code to be reported by gmBasic.  The tool does its best to interpret what it sees, but if there are problems in the source they will often produce problems with the .NET.  It is also very common for an ASP site to contain files that are no longer consistent with the rest of the site.  In many cases these are pages are no longer active and should be omitted from the translation project.  In this way, the upgrade project is a good opportunity to clean up the site by removing the inactive content. 

 

Use the gmBasic pre-compiler

gmBasic has a programmable pre-processor that allows migration teams to modify the source code in memory before it is processed for translation. Conceptually speaking it is a search and replace facility.

If you are changing your source solely to prepare it for migration, it is a best practice to use the pre-process command rather than doing them directly by hand. Using the pre-processor documents the changes, applies them systematically, and makes them repeatable and trackable. This is particularly important if the source code is under active maintenance outside of the migration effort.

In its simplest form, the pre-processor may be invoked by the Compile/Fix or Refactor/EditFIle commands.

1) Compile\Fix\Replace commands are loaded from your main translation script template

<Compile ...>
<Fix host="AppUtilities" name="PreEdits">
   <Replace status="active" name="vbDouble used twice in same Select">
   <OldBlock><![CDATA[
   Case vbDecimal, vbCurrency, vbDouble, vbSingle
   ]]></OldBlock>
   <NewBlock><![CDATA[ 
   Case vbDecimal, vbCurrency, vbSingle 
   ]]></NewBlock>
   </Replace> 
</Fix>
...
</Compile>

 

2) Registry\Edit commands in a GlobalSettings files. This particularly useful for shared files like include files with web sites, and shared modules in VB6 systems.

<GlobalImports>
<Storage Action="Create" Identifier="%UserFolder%\GlobalSettings" />
...
<Registry type="EditFile" Source="%VirtualRoot%Accounts\Litbuildings\lookup_addr.asp"><Fix name="Pre-Edits">
<Replace status="active" name="remove malformed javascript">
<OldBlock><![CDATA[//cal.setHolidays]]></OldBlock>
</Replace>
</Fix>
</Registry>
...
</GlobalSettings>

 

 

 

See Also

Support Statement: VB6 Refactoring

  • No labels