Deploying Applications With InstallShield Express and VFP 8

Andrew MacNeill

AKSEL Solutions


Virtually every application these days needs to be installed. FoxPro used to include a small but under-utilized tool called the Setup Wizard to help developers deploy their applications but with recent versions of Visual FoxPro, Microsoft removed the original ACME Setup and pushed developers towards other tools, one of which was bundled with Visual FoxPro. Let’s take a look at how developers use the InstallShield Express tool to deploy, upgrade and maintain your applications. Along the way, we’ll also take a look at the pitfalls that are very easy for every developer to fall into.

Whatever Happened To…

It wasn’t always like this. Applications could be installed simply by copying a runtime DLL (that was usually five times the size of the application) into the same directory as the application. The downside of this approach is that if you had two or more applications that required the same runtime, you either had to have them in the user’s path or in the same directory. This meant that if you had to update the runtime, they had to be updated in two separate locations. The benefit of that, of course, is that you didn’t have to worry about someone else’s application making yours stop. From a disk space perspective, you may have had lots of duplicate files but generally speaking, it worked!

Even under Windows, where shared files have became more prevalent, you can still have duplicate copies of the same DLLs, although that’s not exactly how an ideal environment was envisioned. Your DLLs have to be registered with the computer to work and since you don’t have exclusive control over the operating system, conflicts may arise. In addition, components and ActiveX controls started becoming an issue. The benefits of re-using someone else’s technology was immediately balanced by the problems caused by upgrades to that same technology that broke your application. This is a very large reason, I believe, that many developers continue to “do it themselves”. 

Enter the Windows Installer

However, if you plan on building commercial quality applications, it always helps to be compliant with Windows standards. Microsoft introduced Windows Installer as a means for managing installations to ensure a few things:

 - ensuring all required files were present

 - allowing users to re-install required files with minimal effort

 - tracking installations so files can be easily removed

 - providing a common experience for all users

Although many different installations may exist, the Windows Installer is the common technology used so all information goes through the same process. The developer, in many cases, does not need to provide the Windows Installer Setup files so the actual size of the setup is smaller as well and better suited for deployment over broadband technologies such as the Internet.

Now, there is one downside of this and that is that the Windows Installer can really only run one at a time so if you are installing multiple applications, it becomes sequential. This isn’t necessarily a bad thing: do you really want users to be installing five things at once?

The Windows Installer uses the concept of Merge Modules (or MSM files) to help deploy shared components. Developers don’t need to know about all of the various DLL files required to install an application – instead you say “give me the XML Merge Module” and it installs what’s needed. This takes the knowledge out of the developer’s hands and we’ll see how this isn’t always a good thing.

The Windows Installer also relies on Product Codes also known as GUIDs. These are those crazy long strings that are wrapped in { } and look like someone dropped a box on the keyboard. The reason for these being so long is that these numbers are actually unique so when Developer A builds a product in San Juan and Developer B builds one in Sydney Australia, it is virtually impossible for their products to have matching GUIDs.

One thing that is important to realize is that you can build your own installations simply using the Windows Installer, which was part of Visual Studio. There are lots of areas that you can customize if you want to dig into how it’s done. However, as with every application, there has to be a better way.


With Visual FoxPro 7, Microsoft replaced the Setup Wizard with a limited edition of InstallShield Express 3.0. With Visual FoxPro 8, we get ISE 3.5. What is InstallShield anyways?


InstallShield is a very powerful deployment tool that comes with its own scripting language and is very feature-rich. As a result, some companies have their own deployment programmers simply to build scripts for installing applications. InstallShield Express was a slimmed down version of this tool, designed to make the deployment process complete with as few clicks as possible.

We’ll get into the details of how to use it in a minute but first the big caveat: this is not the full version of InstallShield nor is it the full version of InstallShield Express. It’s a stripped down version of a slimmed-down product. In both versions for VFP 7 and VFP 8, there are features that are ONLY available in the full version of InstallShield Express. Instead of simply hiding these features, the FoxPro Edition of ISE promotes the features only to tell you that “You must purchase the full version of InstallShield Express to use this feature”. It’s a pain but in today’s age of shameless self-promotion, I suppose it is to be expected.

For those of you who still use Visual FoxPro 7, the bigger problem is that ISE 3.0 did not support upgrades. As a result, deploying new versions of the same application could become troublesome. The new version, included with VFP 8, does and it works quite nicely as we will see a bit later on. The other downside of the VFP 7 version is that although developers could simply select the merge modules they wanted to include, it was never enough to simply include the VFP 7 Runtime merge module. You needed to also include the C++ Library. With the new version, it automatically selects the required runtime files if you select the VFP 8 module.

Application Deployment

The basic structure of application deployment using InstallShield is Organize, Specify, Configure, Customize, Define and Prepare – or at least that’s the way the InstallShield Interface shows it to you. ISE uses a checklist type approach to make it easy to see what steps are still left. Let’s go through each step.


The first step in creating an installation is to provide basic information about your Application including the name, company and version. ISE also provides you with sections to enter in contact information such as the product or company web site and contact support numbers.  This information may accessed by end users with Windows 2000 and XP in the Add/Remove Programs area of the control panel.

The General Information area is also where you specify the installation and database folder. The database folder may be used when you install your data and directories other then off of your main installation directory. When specifying folders, you may force a path (like C:\MYAPP) or use one of the pre-defined folders shown below.


Folder keyword

Description/Typical Folder


Folder where Window's Administrator tools are found.


User's Application Data folder found in the user's personal folder


Common Application Data folder, usually found in C:\Windows\All Users\Application Data


Windows Common files folder, usually found in C:\Program Files\Common.

Database Dir

Database Directory as specified in the General Information section of the setup

Desktop folder

User's Desktop folder

Favorites folder

User's Favorites Folder

Fonts folder

User's Fonts folder (C:\WINDOWS\FONTS)

MyPictures folder

User's Pictures Folder
(C:\My Documents\My Pictures)

Personal folder

User's Personal Folder, usually found in Documents & Settings or Profiles folder in Windows.

Program files folder

Standard Program Files folder, usually defined as C:\Program Files

Program menu folder

User's Program menu folder found off the Start menu folder

Recent folder

User's Recently Accessed Items

Send to folder

Send To Folder where items appear when user right-clicks and chooses Send To in the Windows Explorer.

Start menu folder

User's Start menu folder which may be located in user's directory or Windows folder.

Start up folder

Folder to define which items automatically startup when Windows starts.

System 16folder

Windows System folder for 16 bit support

System folder

Windows folder used for system file

Temp folder

User's Temporary files folder

Template folder

Template folder in user's personal folders

Windows folder

Windows Folder (C:\WINDOWS)

Windows VOL

Volume or Drive where Windows is installed

Pick a folder. IS Express makes it easy to specify "standard" folders for installing files into both application and Windows-specific folders. These folders are handled by the Windows installer, due to the differences in the different operating systems.

InstallShield Express uses a concept of "Features" to allow feature, partial and minimal installs. The "AlwaysInstall" feature set is standard and identifies the bare minimum of what must be installed. However, you can add and remove new features and even subset them into individual items. When adding new features, you may add a description, specify if the feature is required.

Features are then grouped into Setup Types. There are three basic setup types: Typical, Minimal and Custom. A setup must have at least one but you can select what is available to your users. When your setup runs, users are able to drill-down into each individual feature through a Setup Type to identify what will be installed. Below is a sample of a Feature Installation that shows a larger Application that is broken into individual features. 


Adding Features to Setups. ISE makes it easy to add feature-specific installations to your application.

Using the Upgrade Feature

When an application is first defined in the General Information, there are two GUIDs: one for the Product Code and one for the Update Code (see below). With InstallShield, the Product Code must be different for each version of the application to be installed. When the Installer runs, it compares the product codes of the Install to any existing installations in the user's Windows environment. If a user attempts to run a setup that uses the same Product code, a message appears, recommending that they Modify their existing installation. The user must remove the previous version before upgrading.


Note the Upgrade Code! With ISE 3.5, VFP developers can now automatically upgrade applications using the Upgrade Code.

With the new InstallShield Express, developers can specify that a particular installation is an Upgrade by using the same Upgrade code as another installation.  The Product Code must be different to avoid the problem above but the Upgrade code must be the same. Select the Upgrade Paths option under the Organize Your Setup tree.  Add an Upgrade Path by right-clicking on the option. If an MSI (Windows Installer) setup file exists for your original product, select it to have it fill in the details or fill in the details in the right pane (as shown in figure 2).


Figure 2 – Upgrading Your Application. By specifying a minimum version and maximum version, you can determine which customers will get an upgrade.



Some developers I know put the runtime installation in their first install and then remove it from subsequent updates. Unfortunately, with InstallShield's automatic upgrade, it doesn't do a "graceful" update. Instead, when the new installer starts up, it looks for the presence of the older installation. If found, InstallShield will remove the older version before installing the new update.


Specifying the files for your application is a lot easier with InstallShield Express. Select individual files using an Explorer style window and drag them into categories for each of the Feature types set up in the first step. The files can come from any directory accessible on your computer. When you select a file that InstallShield recognizes as having its own MergeModule (such as MS ActiveX controls) it will prompt you to include those modules in the system.  Many vendors now make their runtime MergeModules available for download from their web site. You may also select specific Merge Modules in this step.

If you want to install the VFP 7 Runtime on the user's machine, you can't just specify the VFP 7 Runtime merge modules. You need to also include the Microsoft ® C Runtime Library which includes MSVCRT. With the new VFP 8 ISE, as soon as you select the VFP 8 Runtime, it also automatically includes the C runtime library as well as the GDI library, required for supporting animated GIF files and other image formats.

When you specify the files, you identify the feature it's going to be installed with. For example, you may choose to include sample data that only gets installed when the user selects that option. MergeModules by default are included in the Always Install. Within each item you can create some folders by simply right mouse clicking on the particular feature and creating a new folder.   You can also use the default folders from table 1.

A faster way is to drag and drop the entire "image" directory for the selected feature!


Grabbing Files – You can pull files from any directory and place them anywhere on the user's system!


After specifying the files and merge modules, it's time to configure what your application will look like on the computer after it has been installed. With Install Shield Express, you can configure shortcuts and new folders.  Shortcuts may be added to the Start menu and the Desktop. You can also set up a shortcut to be available in the user's "Send To" menu (which appears when a file is right-clicked on).  Shortcuts may be limited to individual features, receive arguments and may specify a startup directory. You can also configure the registry, setup ODBC resources and make changes to INI files.  When setting values, you can use the predefined values set during the installation such as DatabaseDir.

A particularly useful feature is the ability to set up file types. Setting a file type configures Windows so that when a user double clicks on a file with a particular extension, it automatically launches your application.

A feature that is advertised but not included, is the ability to set environment variables.


You may choose a number of ways to customize the setup appearance for end users however, while a typical install may feature billboards and specialized messages, the InstallShield Express Limited edition limits developers to changing the dialogs themselves.  The good news is that you have many different dialogs to choose from (see below).


Dialog name


Splash bitmap

This is the dialog appears when the user first runs the son of mixed cell

Install welcome (default)

This dialogue welcomes the user to the installation and allows you to specify what application and some basic information about the install

License agreement (default)

If you like you can specify an entire license file in rich text format that will appear before installing. The user is required to click on "I Agree" in order to proceed with the installation. 


A dialog similar to the License Agreement but one that just provides a basic Read Me file.

Customer Information

Prompts the user for their name and company during the install. You may also specify that the user must enter a serial number (see below).

Destination Folder

Allows the user to specify the destination folder for the Install. You can turn off the option that lets the user change the folder if you just want to show it to them. This folder is then accessed for the rest of the install as INSTALLDIR.

Database Folder

Similar to the Destination Folder but useful if you want to separate data from the application. This folder is then accessed as DatabaseDir.

Setup Type

Allows the user to select the type of installation available to them.

Custom Setup

Lets the user specify what custom options are going to be installed.

Ready to Install

Tells the user where the product will be installed and what options are being installed with it.

Setup Progress

The thermometer progress bar may be customized with a custom banner that appears during the install.

Setup Complete

Completion dialog that offers links to Start the program or to view a readme file (both optional).

Customizing your setup. Although you can't have Billboards or customized messages, you can select and customize a number of different dialogs for your setup each with their own customized banner.

Using Serial Numbers

The Customer Information dialog lets you prompt the user for a serial number. When doing this, InstallShield lets you specify a few options, including the format of the serial number ( 555-555,etc) and how many times the user is able to "try" to enter the number. It also lets you specify the Validation DLL that helps validate the serial number. A sample validation DLL is provided in "C:\Program Files\InstallShield\InstallShield Express Visual FoxPro Limited Edition\Samples".  The downside here is that the DLL must be written in C.

Password Protecting Your Version

The ISE included with VFP 8 lets developers password protect the setup. While this isn't the same as serial numbers, you can use this feature to ensure that only valid users install your application.


Under Setup Requirements, specify the requirements related to the machine that is running the installation. Those requirements are limited to choice of operating system, processor, amount of RAM, screen resolution and color depth.  The Full version of ISE also lets you add custom actions to your setup.


After preparing Install Shield Express for your installation, it's time to actually build your setup. InstallShield lets you create separate installations for a variety of formats, including CD, DVD and a single binary format, useful for downloading from the Internet.

Highlight the type of build you want right mouse click and choose a build to actively build the final release.  When creating your build, you may choose a variety of options to include with the installation, including if you want to compress the files and include the Windows Installer Setup for various operating systems. You can also choose to have the Setup create an AutoRun.INF for CD installations.

The actual process is very time consuming and is best left on its own while it finishes. After completing, the log file will tell you if it was successful and any warnings or errors. Warnings will not halt the Setup process but errors will. The log gives you a valuable idea as to the number of files and checks that the Installer will do.

The last two steps listed by InstallShield Express promote best practices for good quality Installations. One step is to test the release; the other one is to distribute it. The final step is almost saying then ship the product -  it isn't something specific that InstallShield will do – it is simply an indicator to say "All Systems go"

Test Your Release!

The section for testing the release however is far more valuable.  There are two options; one to run your setup, which will in fact, install the application on your computer.  The second option is to test your setup - this will run you through the visual interface of the set up without actively installing any software on your computer.  This is a great way of seeing what the user will see during the installation process.

As with building the release, you may choose to test each individual type of build that you've created so you can see the difference between installing it on via a CD-ROM for a Internet download. 

When the release is finally built, you now have to find it! The final setups are created in a folder specified in the options but it defaults to My Documents\MySetups. Within that folder, the final EXE is contained in the "Project Name\Express\Build Name\DiskImages\Diskx". It would be nice if you could actually specify a shorter path however the Limited edition only lets you change the directory of the Setup itself, not the path for the generated EXE.

Automating Your Updates Over the Internet

Many applications today provide automatic updates over the Internet. Some of these updates are manually initiated, like the updates found in Microsoft products, but others are built into the products themselves. InstallShield has started offering a web-based system to provide updates. The InstallShield Update Service ( lets you try it out for 6 months. After 6 months, the cost is listed as $999 for 5000 users, but unlimited updates.

Using the Update service is very easy, although how you decide to handle updates can require some changes. After signing up, your first step is to register your product with the service. When registering the product, you provide the Product Code from your initial InstallShield installation.

Entering Product Info. The Product code must match the product code in the Installation.


After registering your product, you then provide version information. The version entered through this service must match the version listed in your InstallShield Installation.

Entering Version Info.  The version must also match your Product installation in order for the


When you create your InstallShield install, check the option to Enable Automatic Updates. When you do this, the Update client is also installed when the user installs the application. This is the tool that you can use in your application to check for application updates. By default, the Update service prompts the user to check for updates when the application has been installed. However, you can add code into your application that uses the Update client as shown below.


LOCAL loAgent

loAgent = CreateObject( "DWUpdateService.Agent" )

ln = loAgent.AppUpdate("{173D3AE3-3A6F-42C0-B7CD-4E59A0C75FBF}")


You must specify the Product Code that you registered with the Update Service. In addition, this code must be registered on the computer that it runs on as well. If not, the user will be told that the product was not installed properly.


Figure 5 – Setting up Automatic Updates.


By default, the call to AppUpdate will only display results if there is a new version to install. If the user is currently running the application, after the new version is installed, they will be prompted to restart their computer so it can complete. Pass the AppUpdate method a second parameter of zero (0), and the user will not run in "silent" mode and will display a dialog that says "Checking for Updates" and then whatever the results were.


Creating Updates


This is where the process gets a little more complicated. When you have a new version of your application, what happens next depends on how you want to distribute your update. In both cases, select the Messages on the Update Web site and create a message. A message may be either informational or notifying users of a new update. Messages can be categorized and include instructions or not. 




Developers can also choose to Authenticate users, using ASP, CGI or Javascript  on a web site. Updates may be provided as full setup executables or as basic MSI files.  If provided as an MSI file, the following command switch must be entered:




After creating the message, specify what versions the new update message should be applied to. This is very important as the Update Agent will compare the version that is on the user's workstation to the update that is available. If they don't match, there will be no updates to install.


The Update Service provides lots of flexibility. In addition to authenticating users, developers can add specific conditions to see who can get the update. These conditions might be having specific entries in the Registry or specific files that are older than a specific date. This is very useful for incremental updates where you want to update specific files as opposed to the entire application.  Messages may be given expiration dates so updates are only available for certain periods of time.  Messages may also be set to Test so you can verify them before they go out.

When planning a major update that uses the InstallShield update process described above, the process gets a little trickier because the newly installed application will have a brand new product code. This means that the versions referred to by the Update Service need to belong to a brand new product that needs to be added separately as well.

What Gets Updated and What Does Not

When doing major upgrades, the approach of using new product codes and upgrade codes can get a bit time-consuming (as I write this, I have about 5 different InstallShield setups for different versions of the same application). The Upgrade Service is very specific about which versions it will update and which ones it won't. Thankfully, the service provides a Test Utility that allows developers to test out their upgrade messages before they make them active. The Test Utility requires that the initial application be installed but then developers can try out what the messages look like before making them active.


This session should give you enough ideas about how you can use InstallShield to help deploy your application. Of course, it's important to note that if you need to, you can always just copy over the new version of your EXE and install it to keep it going!