InstallShield Tips and Techniques

November 27, 2009

Thoughts on an Automated Build Process

Filed under: Automated Builds, Reference Materials — shieldmaster @ 12:28 am

Phase 1: Requirements for an Automated Build Process – The Automated Build should handle these tasks: 

  • Start with a Clean Build directory – remove all files and directories to achieve a “scorched earth” policy on the Build and Deployment Directory before starting the build process
  • Create the Deployment Directory structure and seed with all 3rd party application files that are not normally incorporated into Source Management repository (if any)
  • Check out Build Number from Source Management repository, increment it, then check in the production Build Number back into the Source Management repository
  • Label all source project files in the Source Management repository with a Build Label using format “Build 2.0.0.XX where XX would be the Build Number.
  • Retrieve all source project files using the Build Label from the Source Management repository
  • Update the Version number resource file that Visual Studio uses to create the file version number using format “2.0.0.XX” where XX would be the Build Number
  • Run Visual Studio batch compile for each solution, creating the binaries (EXE/DLL/OCX)
  • Stage the binaries (EXE/DLL/OCX) to a Deployment Directory and also copy any resource files necessary (bitmaps, help, doc, txt, etc.)
  • Run the InstallShield projects in batch mode that will build the Deployment Setups
  • Stage the Deployment Setups to the Deployment CD-ROM directory along with any documentation PDF’s
  • Stage the Deployment CD-ROM Directory to the Network Share for access by QA/Production teams
  • Archive the Deployment CD-ROM Directory and Build logs to a Network Share directory that has folders created based on Build Number.
  • Create a “Build_Summary.log” that summarizes the Success/Failure of the Build for quick one file viewing
  • Each batch job should create an output Log that allows analysis of the Success/Failure of the Build process
  • Automated Batch process should be able to be scheduled and run after normal working hours ( as late as midnight) – unattended and build correctly

Phase 2: Build Automated Build Process

Development can begin using command line DOS Batch files for first phase – there is no startup costs associated with using this method. Subsequent phase can be developed using a more sophisticated command line tool like ANT, or a graphical tool, such as FinalBuilder or Visual Build – but these require licenses for each seat user.

First, you should create a special UserID, “BUILDMASTER”  for the source manipulation within the Source Management tool (Visual SourceSafe, StarTeam, etc.),  Don’t use an individuals UserID, since the password may be exposed.

The tasks are:

  • Outline each Visual Studio project that needs to be run for the Automated Build, and verify the correct sequence
  • Build the DOS Batch files against the requirements.  Make each separate function a separate batch job to ensure ease in maintenance.  A single Master job will call them in sequence.  This also aids in restarting when an error occurs and the job needs to be started again at the failure point.
    • Set the variables required for the Build to be passed to each job.  This allows for ease in performing Development or Debug build processes or migrating to future releases.
      • Variables might be Build Directories, Source Project Directories, Staging Directories, Production or Debug values
    • Check to ensure a build is not already running.  Exit if the “Build In Progress” indicator is found.  This ensures that two builds are not running concurrently.
    • Create a “Build In Progress” indicator – could be a simple text file written to a special directory.  Same directory could be used to push in status messages (Compiling modules, or building InstallShield program).  These status messages could be echo’ed by a Web Page that provides everyone with the current Build Status.
    • Clean the Build Area.  Ensure all files and directories from previous build are wiped out.
    • Seed the Build area with files and directories that are needed for the Build process, but not stored in the Source Tree
    • Update the Version number and Apply the Label within the Source Tree.  Within this job you will need to retrieve the file “build.number” and any corresponding *.h files from source repository and the Build Number value and then save (put) file back to Source Repository.  Then you will need to apply the “BuildLabel” – format could be “Build”
    • Run a report that reflects which elements are Checked-out or locked by users.   Too late to affect the build, but could be useful in the builds leading to final production build.
    • Run the extraction process to pull the source files from the Source Management tool based on the Build label.  Using this technique will allow you consistent, repeatable build results.
    • Run the compile process for all of the compiled projects. 
    • Run a step that will move the compiled binaries to a Deployment directory.  In addition, copy all of the other files needed for the client installation setup to the correct location in the Deployment directory.  If the Deployment directory is setup to represent the structure of the client installed directory, then QA can easily compare the directory structures (Build Deployment directory  against the results of an installation) to confirm all files were properly installed.
    • Run the batch process that will build the InstallShield (IS) deployment setups.  The IS projects should only pull files from the Deployment directory.
    • Run a batch process that will create a Deployment CD-ROM Directory structure that represents what the client will install the software from.  Copy this structure to a distribution server, using the Build Number as the directory name.
    • Send email to announce the build has completed and note the status (Passed/Failed) to select individuals.
    • Delete the Build In Progress indicator that was created in step #2Test the DOS Batch files to ensure correct functioning
  • Validate the compiled binaries
  • Verify the InstallShield Deployment setups work correctly
  • Ensure the results of each of the Build process steps are written correctly to the “Build_Summary.log” results file. 

Phase 3: Documentation will result in a deliverable that guides team members in understanding the Automated Build process:

  • How to setup the Automated Build process for nightly production runs
  • How to modify the Automated Build process for new modules
  • How to review the Automated Build process for build errors
  • How to restart the Automated Build process when build failure occurred
  • How to make maintenance changes to Automated Build process


  1. Hi ShieldMaster,

    I am following your approach in our build system. A tip, if you work on Windows and use TFS:

    1) I use the Team Foundation Power Tools (tfpt.exe) ‘scorch’ command on a build workspace
    2) I do a ‘get latest’ and perform the build.
    3) Only if the build is successful, I label the workspace (and not the tip in TFS).
    4) I use the MS Build Engine
    5) I also use the MSBuild Community Tasks :
    6) I also use the Microsoft Build Engine (MSBuild) InstallShield 2010:

    Just wanted to let you know.

    Comment by BuildMeister — May 15, 2010 @ 11:04 pm

    • Really appreciate how you are using the latest technology! Good job!

      Comment by shieldmaster — May 16, 2010 @ 10:44 pm

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at

%d bloggers like this: