Navigation:  Introduction > Upgrading from Older Versions >

Upgrading from Visual Build 2/3

Previous pageReturn to chapter overviewNext page

Existing projects created in Visual Build 2 and 3 can be loaded by Visual Build 4+.  However, once saved in Visual Build, the projects will not load correctly into earlier versions.  There are also a few compatibility differences to be aware of when upgrading.

 

Changes that may require project updates

 

Environment variables are no longer reloaded by Visual Build when they are changed by an external program.  Existing projects that use a utility such as SETENV to modify environment variables should be modified to instead use a macro or the Set Macro action, marking the macro to be added to the environment variables.

 

Existing application options will not be copied from a previous version and must be set in the Visual Build options dialogs.  Application options cannot be configured by modifying the registry (they are now stored in an XML file).  To modify options within a project, use the automation object model Application.Options object within a Run Script action.  Some defaults settings are different than the Visual Build 3 defaults.

 

Visual Build provides additional options for handling nesting of build rules and checked status.  To match the behavior of Visual Build, the options to nest build rules, nest include in build status, and re-evaluate build rules should be unchecked.

 

Since global macros are no longer stored in the registry, setting of global macros by modifying the registry is no longer supported.  Script code that does this should be replaced by script expressions or steps with a Set Macro action or a Run Script action that manipulates the Application.Macros objects programmatically via the automation object model.

 

Literal parenthesis and comma characters can now be inserted within macro parameters by using a double parenthesis (( )) or comma character ,,.  Existing projects that include single literal parenthesis characters within macro parameters will need to be changed to use double parenthesis characters.  For instance, %MYMACRO(some text( something else)% would need to be changed to %MYMACRO(some text(( something else)%.  This only affects references to macros that accept parameters.

 

 

Other changes to be aware of

 

If Visual Build 3 is installed, when Visual Build Pro is first started, all the Visual Build global macros (stored in the registry) will be loaded into the Visual Build Pro global macros.

 

Projects created in versions prior to version Visual Build 3 must first be opened and saved in Visual Build 3 before they can be opened in Visual Build Pro 4+.

 

Bracket characters within fields now denote script code; to enter literal bracket characters, use double brackets ([[, ]]).

 

The following conversions are performed when a project from a previous version is opened:
1.Steps with no command or start in path are converted to Group actions.
2.Steps using the SET_TEMP_MACRO or SET_GLOBAL_MACRO macros are converted to Set Macro actions.
3.Steps using the LOGMSG macro are converted to Log Message actions.
4.Step-specific system macros (STEP_NAME, etc.) are converted to the equivalent script code that uses the Visual Build object model.
5.Single bracket chars are converted to double brackets since brackets now denote script code.

 

If the following macros are used in a project, do not uninstall Visual Build 3.  If Visual Build 3 is installed, those macros will also be defined, and will operate correctly, in Visual Build.  If and when those steps are converted to native Visual Build actions, Visual Build Pro3 will no longer be required:
MacroVisual Build Pro Equivalent
PROCMASKProcess Files/Run Program actions
SENDMAILSend Mail action
REGSVRCOM Register action
REGSVREXProcess Files/COM Register actions
REG_WRITEWrite Registry action
ECHOW/ECHOAWrite File action
VSMAKEMake VB6/Make VC6/VS6 Get Version actions
WISEWise Setup action

 

For the Run Program action, the Ignore Fail property now will also ignore a failure to start a process.  Previously, if the process for a command failed to start, the build would fail even if it was marked to ignore failure.

 

The following options are no longer available:
1.No option to determine whether or not to prompt for undefined macros in build rules (will prompt in GUI app unless /s switch was specified on the command-line, will not prompt in console app).
2.The /a command-line switch is no longer supported.
3.No step-specific macros (STEPNAME, STEPOUTFILE, etc.).  Use the equivalent script code ([Step.Name], [Step.OutputFile], etc.).
4.Option to prevent LOGFILE macro from being overridden was removed.