Creating a setup package with InstallShield Express | Deploying Visual FoxPro Solutions

The rest of this appendix is devoted to the creation of a complete setup package for the DeployFox demo app using InstallShield Express. The setup package we use as an example here was created with InstallShield Express version 4.0 SP1. The steps involved and the figures used to illustrate them are substantially the same to those in the other versions of ISX, though, so the information presented here should be applicable to whatever version of ISX you are using.

Note ‚

For another look at creating a setup package for your VFP app using InstallShield Express, please refer to ‚“Walkthrough: Creating a Visual FoxPro Application Setup Program Using InstallShield Express ‚½ in the VFP Help file.

The Sample Application

To illustrate the construction of a setup package using InstallShield Express, we use the DeployFox Demo App as the product to be deployed. This application, developed in VFP 8, is very simple but is intended to be representative of the type of application VFP developers often deploy. It consists of a main EXE file, a ReadMe text file, an HTML help file, a data table with an index, and an ActiveX control file, along with the VFP 8 runtime support files and the VFP 8 HTML Help runtime support files.

Note ‚

The same sample application, called the DeployFox Demo App, is used as an example throughout this book in order to provide as much consistency between chapters as possible.

Creating a new InstallShield Express project

When building a VFP application, you create a VFP project and use the Project Manager to define, organize, and access the various parts of the application. Similarly, when building a setup package with InstallShield Express, you create an InstallShield project and use the InstallShield IDE to define, organize, and access the various parts of the setup package. Your first task when beginning to create a setup package for your application, therefore, is to create a new project.

If you are using ISX VFP LE, you have two choices when creating a new project: use the Project Wizard or create a Blank Setup Project. If you choose to create a Blank Setup Project, you need to fill in all of the required information manually. If you choose the Project Wizard, you are prompted for the required information as you go along. The Project Wizard is a good choice if you are new to the process of creating a setup package using ISX, because it helps you see what information is required. Also, unlike some other wizards, the ISX Project Wizard can be used to edit existing projects, so if you like the Wizard interface you can use it for maintenance as well as for creating new projects.

Using the Project Wizard

To launch the Project Wizard, choose the Project Wizard icon under Project Type and click the Create button, as illustrated in Figure 4 . After the Welcome screen displays, the first step is to give your project a name. This name can be anything you want it to be. Because you may want to maintain separate project files for different versions of your product in the future, you may want to consider including a reference to the version number in your project name , but this is entirely optional and has no effect on ISX. In Figure 5 , you can see that we chose to name our project DeployFox Appendix A Demo App v100 , representing a setup project for version 1.0.0 of the demo app for this appendix.

Figure 4. To create a new InstallShield Express project for your VFP application, choose the Project Wizard or choose a Blank Setup Project. This screenshot was captured from InstallShield Express 4.0, which provides for other project types not found in ISX VFP LE.

Figure 5. The first step in the Project Wizard is to give your project a name.

As soon as you click Next from the wizard step show in Figure 5, a project file with the name you specified is created. As you work through the remainder of the steps in the Project Wizard, the information you specify is written to this project file. Another advantage of using the Project Wizard is you do not need to be concerned with where the information is stored in the project file.

The next step in the Project Wizard prompts you for the application ‚ s name, version, and destination directory on the target computer. In order to differentiate the demo app for this appendix from the demo app for other chapters and appendices in this book, we called it the DeployFox Appendix A Demo App. This is version 1.0.0 of this product, and it ‚ s going to be installed in a folder called DeployFox\AppendixA\Demo App under the user ‚ s Program Files folder as determined by the operating system.

This step is illustrated in Figure 6 . Note that the value in the Default Destination Folder contains the string ProgramFilesFolder enclosed in square brackets. This string, which is placed there by default, is a Windows Installer folder property that resolves to the physical location of the Program Files folder on the target computer at installation time. Specifying a Windows Installer folder property instead of a fixed location such as C:\PROGRAM FILES is preferable because it makes your setup package more flexible.

Figure 6. The Project Wizard automatically supplies the [ProgramFilesFolder] property as the first part of the default destination folder for your product.

Also note that in Figure 6, there is no backslash after [ProgramFilesFolder]. Windows Installer takes care of inserting the required backslash when the value of this property is resolved at installation time.

After prompting you to supply some information about your company, the Project Wizard comes to the step where it asks you to specify the features of your product you want the user to be able to install. Because InstallShield Express builds setup packages for Windows Installer, one of the first things you need to think about when designing your application is how that application should be organized in terms of features and components. For a discussion of the concept of feature and components under Windows Installer, please refer to Chapter 5, ‚“Windows Installer Inside and Out. ‚½ Although you could conceivably lump your entire application into one big feature, that ‚ s not generally the best way to go. For example, even though it is a very simple application, the Demo App is organized into three features:

The main EXE file, the ReadMe file, the VFP 8 runtime support library files, and the ActiveX control file
The HTML Help file and the VFP 8 HTML Help runtime support files
The data table file and its index file

InstallShield Express provides a default feature named Always Install. As its name implies, this feature is intended for files such as your application ‚ s main EXE file that should always be installed. The reason this feature is always installed is that it is marked internally as being required; it is also marked as ‚“not visible ‚½ so it does not show up on the list of features the user sees when a Custom setup is chosen . Other features you add to your setup are typically visible and may or may not be required ‚ both of these are settings you can control.

For the Demo App setup, we have added the two additional features mentioned above. Although features can have sub-features, all of these features for the Demo App are at the root level of the hierarchy, as shown in Figure 7 .

Figure 7. InstallShield Express supplies the Always Install feature by default, but you can add additional features if your application ‚ s architecture calls for them. You should specify a Destination Folder for each feature.

In the Project Wizard, each feature should be assigned to a destination folder on the target computer. Setting the destination folder for a feature sets the destination folder for each file in that feature. Later on, you can change the destination folder on a file-by-file basis if necessary. The value [INSTALLDIR] shown in the Destination Folder field in Figure 7 is another Windows Installer folder property name. This property resolves to the location of the destination folder chosen by the user at installation time. As was the case with the
[ProgramFilesFolder] property we saw before, it is best to use a Windows Installer property name here instead of using a fixed path .

For the Demo App, we use [INSTALLDIR] as the destination directory for the Always Install feature and for the Help Files feature. Because the data files go in a different folder, we set the destination folder for the Data Files feature to a different property called [DATABASEDIR]. We will supply the appropriate value for DATABASEDIR later in the setup process.

The next step of the Project Wizard is to identify the files you want to install, and to associate those files with the appropriate feature(s) of the product. Start by selecting the feature you want to work with from the drop-down list at the top. Next, add the files that belong to the selected feature. When you finish adding the files for one feature, select the next feature from the drop-down list and add the files for that feature. Do this for each feature in the product. Files can be added to the list by right-clicking and choosing Add from the pop-up menu, by dragging and dropping from Windows Explorer, or by clicking the Add Files button and selecting from the Open File dialog. Figure 8 shows the completed step for the Always Install feature of the demo app.

Figure 8. The files DEMOAPP.EXE and README.TXT are installed as part of the Always Install feature.

You probably noticed we have not done anything about the VFP 8 runtime support library files yet. That ‚ s because these files are not added to the setup package in the same way as your application ‚ s files. As we explained earlier, shared files such as the VFP 8 runtime files come pre-packaged as a special kind of file called a merge module, which we incorporate into the project later.

We ‚ re almost done with the Project Wizard now. The next step asks you to define any shortcuts you may want to create for your application. These can include Desktop shortcuts, Start Menu items, and so on. For the Demo App, we want to create only a Desktop shortcut. To create this shortcut, right-click on the Desktop item in the tree view illustrated in Figure 9 to bring up the Browse for Shortcut Target dialog. With Destination Computer selected at the top, navigate to the desired target for this shortcut, which is the DEMOAPP.EXE file located in the [INSTALLDIR] folder. Note that in this step you are pointing to the location of this file on the destination computer, not on your own computer.

Figure 9. When you select the target for a shortcut, you are pointing to the location of that file on the destination computer, not on your own computer.

Note ‚

The Project Wizard in ISX version 4.0 apparently always creates shortcuts configured in a special way known as an Advertised Shortcut. When a user clicks on an Advertised Shortcut, it launches the Windows Installer if it detects the product is missing any components and therefore needs repair. You may prefer to create conventional shortcuts, which can be done in the ISX 4.0 Shortcuts/Folders view. The Project Wizard in ISX VFP 8 LE appears to create conventional shortcuts by default.

After locating the target file in the destination computer ‚ s folder structure as shown in Figure 9, click the Open button to select it and return to the main window in the Project Wizard. Give your shortcut a name and press the Enter key to finish the creation of this shortcut. Repeat the procedure for any other shortcuts you may want to create. The completed Desktop shortcut entry is shown in Figure 10 .

Figure 10. This step of the Project Wizard defines a Desktop shortcut and points to the EXE file (DEMOAPP.EXE) for the application on the destination computer.

The important elements of the setup project are now in place. The next two steps of the Project Wizard prompt you for registry information and allow you to choose whether to include certain dialogs in the setup wizard the user sees at installation time. In the second category, one of the default settings is to include a license agreement dialog; you can uncheck this setting if you do not want to include a license agreement as part of your application ‚ s setup.

The final dialog in the Project Wizard is a summary of the basic information for the setup, as shown in Figure 11 . At this point, you can still back up within the wizard and change things if you want to. If the basic information is okay don ‚ t be too concerned about every detail being correct at this point, because you will be able to modify your project using the InstallShield Express IDE before building the setup package. In the case of the Demo App, in fact, we have to make some modifications before we can build a release ‚ among other things, we still need to add the merge modules for the VFP 8 runtime support library files, for the VFP 8 HTML Help support library files, and for the ActiveX control used by this app. For that reason, we uncheck the Build a Release check box on the last step of the Project Wizard, as shown in Figure 11, and defer the building of the setup package until after we finish our modifications.

Figure 11. The final step in the Project Wizard summarizes the basic information for the setup. If changes are necessary after this step, they can be made directly to the project file via the InstallShield Express IDE.

Using the InstallShield Express IDE

When the Project Wizard finishes, it opens the project in the main InstallShield Express IDE. You can now make any necessary changes or additions to the project before actually building the setup package.

One advantage of using the Project Wizard to create a new setup project is you don ‚ t have to know what entries are required or where they go in the project organizer. All of the entries you make in the various steps of the Project Wizard are written to the appropriate places in the project for you. Later, as you step through the open project in the ‚“Organize Your Setup ‚½ section of InstallShield Express, you can see where the information you specified in the Project Wizard has been stored.

If you choose to start with a Blank Setup Project instead of using the Project Wizard, InstallShield Express opens a blank project in the ‚“Organize Your Setup ‚½ interface and you have to fill in the required entries by hand. Once you become familiar with InstallShield Express, you may find you prefer to build your new projects from scratch and not use the Project Wizard any more.

Figure 12 shows the Demo App project open in the main InstallShield Express IDE. You navigate through the various steps in the project organizer by selecting them in the tree view on the left, and then entering or modifying their corresponding entries in the pane on the right. The steps in the tree view are arranged from top to bottom in their natural sequence, and the idea is you walk through a project from start to finish by working your way down the steps in the tree view. As you finish with one step and move to the next, a red check mark appears next to the steps you finish so you can keep track of where you ‚ ve been.

Figure 12. The project file is opened for editing when the Project Wizard finishes. The Organize Your Setup interface is the same interface you use when you open an existing project manually, or when you create a Blank Setup Project.

Different applications have different setup requirements, and you typically do not need to use all of the available sections of the project organizer for every application. If you are using ISX VFP LE, you will find several of these sections disabled due to the feature limitations in ISX VFP LE, as noted earlier in this Appendix.

Although some of the later steps use information you specified in earlier steps, nothing prevents you from going back to a step you already worked on earlier, so don ‚ t worry about jumping around or about skipping a step if you know you don ‚ t need it.

General Information view

Some of the early information we supplied to the Project Wizard is shown in the General Information view. For example, in Figure 13 you see the Product Name and Product Version as well as the value we specified for [INSTALLDIR]. Any or all of this information can be edited from this view.

Figure 13. The Product Name, Product Version, default values for INSTALLDIR and DATABASEDIR, among other things, are specified in the General Information view.

Remember that earlier, in the Project Wizard, we set things up so the Data Files feature would be installed to the DATABASEDIR folder. Now we need to supply the default value for that folder. The Demo App expects to find its data files in a sub-folder named Data under the folder where the application itself is installed. (This of course is not true of all apps; it ‚ s just the way the Demo App was designed. Your app may be different.) The default value of the DATABASEDIR property is [INSTALLDIR]Database, but for this app we need to change it to [INSTALLDIR]Data, as shown in Figure 13.

Whether or not you plan to change the entries in any of the remaining steps in the project organizer, you may still want to click through each one of them just to see what ‚ s in them. In the interest of space, we won ‚ t discuss or present a screenshot for every one of the remaining steps, only for those that merit special attention for the Demo App.

Setup Types view

The Setup Types view has two parts: the upper pane is a list of the setup types (Typical, Minimal, and Custom), and the lower pane is a list of the features defined for this product. To associate feature(s) with a setup type, select the setup type in the upper pane, and then select or clear the desired feature(s) in the lower pane. For the Demo App, the Typical setup and the Custom setup install all three features, but the Minimal setup does not install the Help Files feature. In Figure 14 , you can see the Minimal setup type is selected in the upper pane and the Help Files feature is cleared in the lower pane.

Figure 14. The Setup Types view is used to link the product ‚ s features to the setup type(s) with which they are to be installed.

Files view

The Files view is used to define the files to install and to associate each file with the feature to which it belongs. To use this view, first select a feature from the drop-down list at the top. For example, in Figure 15 the AlwaysInstall feature is selected. Use the upper two panes to select the files to be installed. Use the lower two panes to specify the location for these files on the destination computer. You can drag a file name from the upper right pane to the lower left or lower right pane to place it in the project. Because we specified the files in the Project Wizard, you can see they already show up in the lower panes of this view in Figure 15.

Figure 15. In the Files view, first select a feature from the drop-down list at the top. Next, select the source files from the upper panes and drag them to the appropriate folder in the lower panes.

File properties

Once files are added to your setup project, you can open a properties sheet for a file or for a group of files by selecting them in the lower right pane of the Files view, right-clicking the selection, and choosing Properties from the shortcut menu. The properties sheet allows you to set system file attributes such as Hidden or Read-only on the selected files. It also allows you to set Windows Installer attributes such as Never Overwrite and Permanent, as well as to limit the installation of the selected files to one or more specific version of Windows if necessary.

Data files

Data files need special consideration, and you need to do some pre-planning to avoid potential problems when future updates are installed or when the product is uninstalled . What you want to prevent is a user ‚ s data files being overwritten during the installation of an update, or a user ‚ s data files being removed during uninstallation of the product. Windows Installer makes a provision for these situations, and InstallShield Express gives you access to the appropriate settings at the file level.

According to the file versioning rules used by Windows Installer, non-versioned files (files that do not carry version information) are not overwritten during an update if the file ‚ s Modified date is different from its Create date. This provides a certain amount of protection for files such as VFP data tables and index files, which are ordinarily updated by the user after the app is initially installed and before an update is installed. You can provide an additional measure of protection for user data files by marking them as Never Overwrite. To protect against the removal of a user ‚ s data file during uninstallation of the product, you can also mark them as Permanent.

Both of these settings are made by right-clicking each file in the Files dialog, selecting the Properties sheet, and selecting the appropriate check boxes on the Advanced page, as illustrated in Figure 16 . Multiple files can be selected and their settings modified in one step.

Figure 16. Files can be marked as Never Overwrite and/or Permanent on the Properties sheet available from the Files view. Properties can be set for multiple files at the same time.

Warning ‚

In this author ‚ s experience, attempting to set these properties from within the Project Wizard causes an ACCESS_VIOLATION (0xC0000005) error that terminates InstallShield Express. This is true under both ISX VFP8 LE and ISX 4.0 SP1 (full version). This error, which is evidently not documented, occurs only from within the Project Wizard; it does not occur if these properties are set from the Files view of the main InstallShield Express IDE, as illustrated in Figure 16.

New folders

In addition to working with files, you can also use the Files view to add new destination folders to your project. You can choose one of the several pre-defined folders supplied by ISX (such as [AppDataFolder], [CommonAppDataFolder], [DesktopFolder], [TempFolder], etc.) or you can add a custom folder and give it a name of your own choosing. To add a new folder, right-click the parent location in the lower left pane of the Files view. Then, from the shortcut menu, choose Show Predefined Folder to pick a folder from the list of pre-defined folders, or choose Add to add a folder and give it a custom name. For example, if your app requires the file MYFILE.DBF be located in a folder named MYAPPS under the All Users Application Data folder on the target computer, first add [ComonAppDataFolder] under Destination Computer, and then add a custom folder named MYAPPS under [CommonAppDataFolder]. Finally, select the MYAPPS folder in the lower left pane and add MYFILE.DBF to the lower right pane of the Files view. The completed process is illustrated in Figure 17 .

Figure 17. You can add new destination computer folders to your setup using the Files view.

Files and features view

The Files and Features view (not shown) is useful because it shows you, in simple list form, which files to install with which features. We already made these assignments in the Project Wizard, so for the demo app no changes are necessary in this view. You may want to open this view and see how it looks, though, if only to become familiar with it. If necessary, you can make changes to the assignment of files to features in this view by simply dragging a file from one feature to another.

Redistributables view

The Redistributables view (called the Object/Merge Modules view in ISX VFP8 LE) is where you bring in the merge modules containing the VFP 8 runtime support library files, the VFP 8 HTML Help support library files, and the MSCOMCTL.OCX ActiveX control file required by the demo app. The nice thing about merge modules is they are pre-packaged: you do not need to specify the files individually, and because they are typically system files (or at least shared files) they are already targeted for pre-defined folders so you don ‚ t need to specify a destination for them.

The merge modules we need for the Demo App are the following:

Microsoft Visual FoxPro 8 Runtime Libraries (VFP8RUNTIME.MSM)
Microsoft Visual C++ 7 Runtime Library (MSVCR70.MSM)
GDI Plus Redist module (VFP_GDIPLUS.MSM)
Microsoft Visual FoxPro 8 HTML Help Support Library (VFP8HTMLHELP.MSM)
Microsoft Windows Common Controls 6.0 (MSCOMCTL.MSM)

To select a merge module for inclusion in your project, locate it in the alphabetical list of merge modules in the upper left pane of the Redistributables view and select its check box. The only other thing you have to do is assign each merge module to a setup type. In the Demo App, we want the VFP 8 Runtime Libraries and the Windows Common Controls merge modules to be installed with the AlwaysInstall feature. The VFP 8 HTML Help Support Library merge module is not needed unless the Help Files feature is installed, so we associate that merge module with the Help Files feature only, as shown in Figure 18 .

Figure 18. Merge modules are added to the project in the Redistributables view. Use the upper right pane to associate each selected merge module with the desired feature.

Note ‚

In the upper right pane of the Redistributables view, the AlwaysInstall feature is selected by default. It cannot be cleared until another feature is selected, because a merge module, like a file, must always be associated with at least one feature.

In our opinion, one of the nicest improvements in ISX version 4.0 over previous versions is version 4.0 displays a lot more information about merge modules, including the files they contain. Figure 19 is an expanded view of the information available about the VFP 8 Runtime Libraries merge module, taken from the lower left pane of the Redistributables view. Normally, not all of this information is visible at once, but you can scroll through it or you can expand the size of the pane to see more of it at once, as we did to capture this screenshot. Although it takes two side-by-side images to display here, it ‚ s actually only one pane (the lower left) in ISX.

In addition to the two VFP 8 runtime DLLs, VFP8R.DLL and VFP8T.DLL, you need to include a language resource file. As you can see from Figure 19, the VFP8RUNTIME.MSM merge module already includes the U.S. English language resource file VFP8RENU.DLL, so if all you need is U.S. English you do not need to do anything else to include that resource file in your project. There are separate merge modules for each of the other language resource files, which you can include if you need them.

Figure 19. InstallShield Express 4.0 can show you what ‚ s inside a merge module. This is very useful for confirming a particular merge module includes the file(s) you want to install. The VFP8 Runtime Libraries merge module installs three files.

In addition to the VFP 8 runtime support library files, applications developed in VFP 8 also require the GDI-Plus DLL and the Visual C++ version 7 runtime support files. Selecting the VFP8RUNTIME.MSM merge module automatically selects the merge modules for the Microsoft Visual C++ 7 Runtime Library and the GDI Plus Redistributable, so you do not need to select those two merge modules manually. When working with a VFP 7 app, you have to select the Visual C++ 7 Runtime Library merge module manually, in addition to the VFP 7 runtime support library merge module. VFP7 apps do not require the GDI Plus Redistributable.

Shortcuts/Folders view

Although we already created the Desktop shortcut in the Project Wizard, we have one additional thing to add to it. The Project Wizard did not allow us to specify the working directory for the shortcut, and depending on how your app is designed, it may be necessary to specify the app ‚ s install folder as the shortcut ‚ s working directory. To do this, use the Shortcuts/Folders view, select the Desktop shortcut in the tree view, edit the Working Directory entry in the upper right pane, and select [INSTALLDIR] from the drop-down list, as shown in Figure 20 . Of course, if your app requires a different working directory you would use whatever value is appropriate.

Figure 20. The value for a shortcut ‚ s Working Directory can be selected from a drop- down list in the Shortcuts/Folders view.

Registry view

The Registry view makes it easy to create registry entries on the destination computer during installation of your product. Like the Files view, the Registry view is arranged into four panes: the two upper panes represent the source computer (your computer) and the two lower panes represent the destination computer (the user ‚ s computer). Also like the Files view, the Registry view has a drop-down list at the top where you can choose the feature with which you want the registry entries to be installed.

If the registry entries you want to create on the user ‚ s computer already exist in the registry on your computer, you can simply drag them from the Source Computer pane in the Registry view and drop them onto the appropriate location in the Destination Computer pane. You can drag and drop entire keys, in which case all subkeys and values are also included, or you can drag and drop individual values.

If the registry entries you want to create on the user ‚ s computer do not already exist in the registry on your computer, you can still instruct your setup package to create them on the user ‚ s computer. This can be done either by importing a REG file into your setup project or by creating the necessary keys and values individually in the Destination Computer pane of the Registry view.

To import a REG file, right-click the desired registry location in the Destination Computer pane in the lower left of the Registry view, and choose Import REG File from the shortcut menu. This launches the Import REG File Wizard, which walks you through the steps of including a REG file in your project.

To add registry keys and values individually, right-click the desired hive of the Destination Computer in the lower left pane of the Registry view, and choose New from the shortcut menu. From this menu, you can add the new keys and new values to be written to the destination computer ‚ s registry.

Sometimes you may want to specify a literal data value for a registry entry, while at other times you may want to pick up the value of a Windows Installer property. For example, you might want to write a registry entry that captures the full drive and path of the folder where the product is being installed. This information, of course, is available as the runtime value of the [INSTALLDIR] property. To capture this value and store it in the registry, you can create a registry entry named AppPath, for example, and specify [INSTALLDIR] as its data. This is illustrated in Figure 21 .

Figure 21. You can use the Registry view to create registry entries on the user ‚ s computer. The entry shown here stores the path to the folder where the product is being installed by capturing the runtime value of the [INSTALLDIR] property.

The HKEY_USER_SELECTABLE root key shown in Figure 21 is a pseudo-key provided by InstallShield Express. Registry entries that you create under this key in the Registry view are written to the HKEY_CURRENT_USER hive of the user ‚ s computer if a per-user installation is performed or to HKEY_LOCAL_MACHINE hive if a per-machine (all users) installation is performed.

ODBC Resources view

Whether or not your application itself requires it, you may want to make it possible for your users to access your product ‚ s database via ODBC. To facilitate ODBC access to your data on the user ‚ s machine, you probably want to create and install a Data Source Name (DSN) in addition to installing the required ODBC components.

Data source names

To illustrate the use of a DSN, we created a system DSN named DeployFoxSample on our development machine. This DSN provides access to the CUSTOMERS.DBF table in our demo app ‚ s Data folder. Because the demo app does not use a database container (DBC), the DeployFoxSample DSN points to the free table CUSTOMERS.DBF. In a real application you would typically have a database container (DBC), and you would usually want to set up the DSN to point to the DBC instead of to an individual DBF.

To add the DeployFoxSample DSN to the project, open the ODBC Resources view and select the DSN from the tree in the upper left pane, as shown in Figure 22 . Note that in order to appear in the tree, the DSN must exist on your development machine. To install a DSN that does not exist on your development machine, you can right-click the DSN ‚ s node of the tree and add a new DSN on the fly.

Figure 22. Add a DSN to your project by selecting it from the tree in the ODBC Resources view.

Once a DSN has been added to the project, you can see and edit its attributes in the upper right pane of the ODBC Resources view. One attribute of this particular DSN needs to be mentioned here, and that ‚ s the SourceDB attribute. This attribute contains the path to the DSN ‚ s source data, which may be different on the destination computer than it is on the source computer. Because the DeployFoxSample DSN was created on our development machine and was added to the project by selecting it from the DSN tree, the default value of the SourceDB property for this DSN is the path to CUSTOMERS.DBF on our development machine, namely C:\DEPLOYFOX\DEMOAPP\DATA. On the user ‚ s computer, the CUSTOMERS table is most likely not in this folder; it will be in the Data sub-folder of the folder where the user chooses to install the application. Although we know the default value for this folder is C:\PROGRAM

FILES\DEPLOYFOX\APPENDIXA\DEMO APP\DATA, it could be different if the user chooses to install the product to a location other than the default. Therefore, we don ‚ t want to use that literal value for our DSN ‚ s SourceDB attribute either.

In fact, we don ‚ t want to use any literal value for SourceDB. To make the DSN portable ‚ in other words, to set it up so it points to the CUSTOMERS.DBF table regardless of where the application is installed ‚ we need a variable whose value is the location of the data when the product is installed. By now you probably realized the DATABASEDIR property meets this requirement, so we can set the value of the SourceDB attribute of the DSN to [DATABASEDIR], as shown in Figure 22.

Visual FoxPro ODBC driver

If you are deploying a DSN that uses the Visual FoxPro ODBC driver, you should also deploy the Visual FoxPro ODBC driver itself. You may also want to deploy the latest Microsoft Data Access Components (MDAC). Both of these are supplied as merge modules, which you can select in the Redistributables view. Figure 23 shows the VFP ODBC merge module selected for inclusion in this project. Note that ISX displays the contents of this merge module in the lower left pane, where you can see it includes the file VFPODBC.DLL. Again, the ability to display the contents of a merge module was added to ISX in version 4.0.

Figure 23. Add the Visual FoxPro ODBC merge module to your project using the Redistributables view. Note that the contents of this merge module are shown in the lower left pane in ISX 4.0.

Because ODBC is now somewhat outdated (having been superseded by OLE DB), the Visual FoxPro ODBC driver is no longer included in the Microsoft Data Access Components as of MDAC 2.6. In addition, as of VFP 8, the Visual FoxPro ODBC driver and the VFP ODBC driver merge module (VFPODBC.MSM) are no longer installed with VFP. If you do not already have them from an earlier version of VFP, you can download these files from the VFP downloads page on the Microsoft MSDN Web site ( http://msdn.microsoft.com/vfoxpro/downloads/updates/default.aspx ).

VFP OLE DB provider

As data access technologies advanced beyond ODBC, OLE DB became the preferred way to access data. An OLE DB provider for VFP was introduced with VFP 7 and updated with VFP 8. If you want to enable OLE DB access to your data, you should install the Visual FoxPro OLE DB provider along with your product. This is easily done by including the merge module VFPOLEDB.MSM in your project. This merge module installs the VFP OLE DB Provider file VFPOLEDB.DLL.

Other views

As you look down the list of steps in the project organizer, you see several other views before you get to the Build Your Release view near the bottom. For example, there is a view for creating IIS virtual directories as well as a view that gives you the ability to specify minimum environmental requirements for your app (Windows version, Internet Explorer version, MDAC version, etc.). Other views enable you to modify the way the setup wizard looks to the user by choosing which dialogs to display and, if desired, even changing the wording of the standard InstallShield messages.

For many apps, however, these additional steps are not needed. This is true of the Demo App, so we will not spend any time looking at these other views here. Like the views we already explored, most of the others are fairly self-explanatory and are easy to manipulate once you have the hang of working in the InstallShield Express IDE. When questions arise, the InstallShield Express documentation is quite good and will normally provide you with the answers you need.

Building the setup package

The final step prior to deployment is to build the setup package. Building the setup package is known as ‚“building a release ‚½ in InstallShield terminology, and there is a view called Build Your Release near the bottom of the tree view used for this purpose. Building the setup package is as simple as clicking the Build button on the ISX toolbar. However, you need to make a couple of decisions first.

Choosing the type of build

One decision you need to make is what type of setup package you want to build. You can choose from several pre-defined types. A SingleImage build creates a single EXE, which is easy to distribute but is perhaps not optimal for all situations. A CD_ROM build creates individual files and organizes them into the appropriate folders and sub-folders suitable for copying to a CD-ROM. A DVD build is similar to a CD_ROM build but the setup is optimized for a particular size of DVD, from which there are several to choose. A Web Deployment build creates a setup package designed to deploy over the Web, and a Custom build can be used to create setup packages for other types of deployment media not listed as one of the standard options.

To choose the type of build you want, simply select it from the list by clicking it. Once a type of build is selected, the set of choices for that type of build display in the upper right pane.

Creating a setup launcher program

We already mentioned that InstallShield Express builds setup packages for Windows Installer. This is true regardless of the type of build you choose. A Windows Installer setup package includes an MSI file, which is a database containing all of the instructions the Windows Installer service needs to install the product. See Chapter 5, ‚“Windows Installer Inside and Out ‚½ for details on MSI files and on how Windows Installer works.

In addition to the MSI file, a Windows Installer setup package can include a setup launcher program called SETUP.EXE. When you build your setup package, you can decide whether to create SETUP.EXE. Ordinarily you will probably want to do this, because it ‚ s convenient for your users to simply run SETUP.EXE to install your product. If you don ‚ t create a SETUP.EXE, your users have to install the app from the MSI file itself, which not all users will know how to do.

Including the Windows Installer setup engine(s)

If you do choose to create a SETUP.EXE program, you can then choose whether to include the Windows Installer engine(s) as part of your setup package. Windows Installer is a native part of Windows Me, Windows 2000, and Windows XP, and is available as a redistributable for older versions of Windows. These days you can be reasonably confident your user ‚ s machine already has Windows Installer on it, but you can ‚ t be certain. In addition, there is more than one version of Windows Installer, so even if a user does have Windows Installer on their machine it may be an older version than the one your setup requires. ^[4]

To address these uncertainties, you can elect to include the Windows Installer engine(s) in your setup package. You can choose to include the Win9x setup engine, the NT setup engine, both, or neither . The safest choice is the default, which is to include both. The only downside to this choice is your setup package will be larger due to the size of the setup engine(s). This is probably not a concern with a CD_ROM or a DVD type of release, but may be a consideration with a Single Image or a Web Deployment setup package because the setup package may need to be downloaded by users with low-speed connections.

Figure 24 shows the Build Your Release view with the Single Image type selected in the tree view. In the upper right pane, you can see the choices for including or not including the Windows Installer setup engine(s). In this example, both are selected.

Figure 24. When building your release, you can choose the type of setup package you want. You can also decide whether to include the Windows Installer setup engine(s).

To see what the resulting size difference would be, we built a Single Image setup package for the Demo App both with and without the MSI engines. With both MSI engines included, the setup package was 11,753KB (11.4MB); with neither engine included, the setup package was 8,304KB (8.11MB). All other things being equal, then, the MSI engines appear to require about 3.3MB in a Single Image build using compressed media (i.e., CAB files).

Testing your setup

One nice feature of InstallShield Express is it allows you to test your setup package on your own machine without actually installing the product. Testing a release walks you through all of the steps in the setup process so you can see if everything looks the way you want it to before deploying your product. Of course, you can always perform an actual install of the product on your own machine, but there may be reasons why you would not want to or would not be able to do this. For example, installing a user DSN could overwrite your development DSN of the same name ( potentially with different settings), and installing an ActiveX control with a user license could eliminate your developer ‚ s license for that control. The Test Your Release view gives you the choice to either test the setup or to actually run the setup and install the product.

Deploying the application

You ‚ ve done everything necessary to build the setup package. Now it ‚ s time to actually deploy the application to your users. All that ‚ s really involved here is copying the setup file(s) from your computer to the deployment media ‚ be it CD-ROM, DVD, Zip disk, or FTP to a Web server ‚ but there is more than one way to do this.

Using the Distribute Your Release view

Although you can easily copy your setup file(s) to their distribution media without using InstallShield Express, ISX does provide you with a final view to facilitate this step. Choosing the Distribute Your Release view brings up a tree view of the various build types, just like the Build Your Release view, and in the right-hand pane it provides a mechanism for you to copy the file(s) for the selected build type to the media of your choice.

The Distribute Your Release view is shown in Figure 25 . To use this view, select the type of setup you want to distribute ( SingleImage in this example). Then, in the right pane, select the destination to which you want to copy the setup files. For example, if you are going to distribute your single image SETUP.EXE on a CD, use the Browse button to select your CD-RW drive and folder (D:\ in this example) and click the Distribute to Location button to copy the setup files to that CD. If you are going to make the SETUP.EXE file available for download from a server, you can use the FTP Distribution portion of this view to send the setup file(s) to the server.

Figure 25. The Distribute Your Release view makes it easy to copy your setup file(s) to the desired distribution media.

Copying your setup files manually

One advantage of using the Distribute Your Release view is you don ‚ t need to know where the setup package physically resides on your computer. However, if you ‚ re like us, you like to know where things are and what ‚ s going on, so we ‚ re going to tell you. The setup file(s) created by InstallShield Express are placed in a sub-folder beneath the folder where the ISX project is located. The sub-folder has the same name as the project. Under this sub-folder there are several other sub-folders; one of them has the name of the type of build you chose. This naming convention allows setup packages for more than one type of build to coexist on the same computer at the same time.

Underneath the sub-folder for the type of build, two levels down, is a folder named DISK1. This is the root folder for the setup files created when you build that type of release. Depending on the type of build and the overall size of the deployment files, there may be more than one DISKX folder in your setup ‚ s output folder structure. In any case, InstallShield Express creates the necessary folder structure as part of its build process.

Figure 26 illustrates this folder structure for the Single Image build of the Demo App. The output file SETUP.EXE is located in the folder named DISK1. If you want to create your distribution media manually, you can simply copy the distribution file(s) from there to the appropriate media. If you created a single image build, the only file you need to distribute is SETUP.EXE. If you created a CD-ROM type of build, on the other hand, there are several files in DISK1 and also sub-folders under DISK1 containing the other files that are part of your setup. If you are copying files to your distribution media manually, be sure to include all of these files and sub-folders. If your build created other DISKX folders, they and their contents need to be copied to the appropriate media, too.

Figure 26. The files created when you build a release are placed in a sub-folder beneath the folder where the setup project itself is located. The root of the sub-folder structure for a particular build is the folder whose name is the same as the build type.

^[4] By default, InstallShield Express builds setup packages for version 2.0 of the Windows Installer, which is the current version as of this writing.