Chapter 15
Setup and Deployment

Last, but not least, we address the setup and deployment issues with respect to the changes in Visual FoxPro 9.

Setup and deployment are not the first topics Visual FoxPro developers think about when they hear a new version of their favorite development tool is nearing release. Sure, developers realize new run-time files are inevitable and there could be new file dependencies for the run-time, so why an entire chapter dedicated to this topic? How about better support for Terminal Services? How about the ability to capture coverage logs during run-time? How about a brand new version of InstallShield Express Visual FoxPro Limited Edition? We address these topics and more in this chapter, so read on!

New run-time files

Applications updated and released after a Visual FoxPro version upgrade require all the new run-time files ship with your application. It is very important to keep the run-times synced with the development version of Visual FoxPro. So what files do you need to distribute?

The Visual FoxPro Help file discusses the various run-time files in the “Visual FoxPro Run-Time Libraries” topic.

There are a few directories to check for new run-time files. Your directories could be different depending on the operating system and the directory structure where you installed Visual FoxPro. For Visual FoxPro 9 you have the following files:

· C:\Program Files\Common Files\Microsoft Shared\VFP\ contains the VFP9R.DLL (main run-time library) and VFP9T.DLL (multi-threaded run-time) files. The language resource files: VFP9RChs.DLL (Chinese, Simplified), VFP9RCht.DLL (Chinese, Traditional), VFP9RCsy.DLL (Czech), VFP9RDeu.DLL (German), VFP9REnu.DLL (English), VFP9REsn.DLL (Spanish), VFP9RFra.DLL (French), VFP9RKor.DLL (Korean), and VFP9RRus.DLL (Russian). Finally, FOXHHelp9.EXE and FOXHHelpPs9.DLL (HTML Help system run-times), and GdiPlus.DLL (graphics dependency file).

· C:\Program Files\Common Files\System\Ole DB\ contains VFPOleDb.DLL (Visual FoxPro OLE DB Provider).

· C:\Program Files\Common Files\Merge Modules\ contains the merge modules used by InstallShield Express and other install tools that leverage the Windows Installer technology. These files include VFP9RChs.MSM, VFP9RCht.MSM, VFP9RCsy.MSM, VFP9RDeu.MSM, VFP9REsn.MSM, VFP9RFra.MSM, VFP9RKor.MSM, VFP9RRus.MSM, VFP9Runtime.MSM, VFP9HtmlHelp.MSM, VFPOleDb.MSM, VFP_GdiPlus.MSM, and VFP9RptApps.MSM. The merge modules are not directly distributed to
the customers.

The Visual FoxPro 9 version of VFPOleDB.DLL/MSM overrides the same named files installed with VFP 7 and 8. Microsoft recommends distributing the latest version of this file, even if your applications are released with Visual FoxPro 7 or 8 run-times.

The Visual FoxPro 9 version of the GdiPlus.DLL and VFP_GdiPlus.MSM files install over the exact named files previously installed by Visual FoxPro 8. This means your Visual FoxPro 8 applications are distributed with the graphics library installed with Visual FoxPro 9. Microsoft notes the new version is completely backwards compatible and will not have a negative impact on your Visual FoxPro 8 releases.

New run-time dependencies

The Visual FoxPro 9 run-times have a new dependency, the Microsoft C Runtime Library 7.1 (MSVcR71.DLL). This replaces the dependency of Microsoft Visual C++ 7.0 Runtime in Visual FoxPro 7 and 8. The merge module for this file is C:\Program Files\Common Files\Merge Modules\VC_User_Crt71_Rtl_X86_---.MSM. If you are deploying this file without Windows Installer and the merge module, you should install this file in the WinSysDir folder (on Windows XP this would be the Windows System32 folder).

If you are using the new reporting functionality, you need to include ReportPreview.APP and ReportOutput.APP with your application unless you create your own preview code. You also need to distribute ReportBuilder.APP if you allow users to modify reports and want them to use the new dialogs. See Chapter 5, “Enhancements in the Reporting System,” for details on these APP files. The Fox Team included a new merge module for easier deployment with Windows Installer tools. The merge module is C:\Program Files\Common Files\Merge Modules\VFP9RptApps.MSM and is called Microsoft Visual FoxPro 9 Report Applications.

Some developers feel releasing an APP file externally from the primary executable exposes a security risk because the APP can be replaced with rogue code to intercept report information. Fortunately, the source code for ReportBuilder.APP, ReportPreview.APP, and ReportOutput.APP comes with VFP (unzip XSource.ZIP in the Tools\XSource subdirectory of the VFP home directory). If you include this source code in your project, there is no need to distribute the APP files. Instead, add the following code to your main program, application object, or report object to set the Report Designer system variables to the main PRG of each of the APP files:

_REPORTPREVIEW = "FrxPreview.prg"

_REPORTOUTPUT = "FrxOutput.prg"

_REPORTBUILDER = "FrxBuilder.prg"

EXTERNAL PROC FrxBuilder

EXTERNAL PROC FrxPreview, FrxOutput

The first time you build your project, the Project Manager prompts you to locate FrxBuilder.PRG, FrxPreview.PRG, and possibly one or two additional files, found in the ReportBuilder and ReportPreview folders under Tools\Xsource. It then adds all the necessary components normally compiled into the APP files to your project. Another approach includes setting the three Report Designer system variables in the application Config.FPW and include the EXTERNAL PROC in the main program.

If you are deploying run-time-based IntelliSense in your applications, you need to deploy FoxCode.APP, which uses FoxTools.FLL.

Minor operating system requirements change

Windows 2000 still supports developing applications with Visual FoxPro 9, but it now requires Service Pack 3 or later. Visual FoxPro 8 only requires Service Pack 2. You can create and distribute run-time applications for Windows 98, Windows Me, Windows 2000 Service Pack 3 or later, and Windows XP. Again, only the Service Pack for Windows 2000 changed in this version.

SET COVERAGE command available at run time

Have you ever had a customer call and ask why a certain feature is running slowly? You test it at your office with your test data and the code performs as expected. You have the client send you a backup copy of their data and the error logs. You install it and it still performs snappily. Frustrated, you confirm the configuration of the customer’s computers and find out they are better machines than the one you are using to test on. So why is it running so darn slow? It sure would be nice if your client had a license of Visual FoxPro, but they don’t. You could run a coverage log on the code in production to see what the problem is, but unfortunately, the SET COVERAGE command is one of those commands ignored at run-time. That is, ignored until Visual FoxPro 9!

The Coverage Profiler is an excellent tool to identify the bottlenecks in your application as well as what code is not executed. It allows Fox developers to be more efficient at problem solving in the development environment. The Coverage Profiler is not available at run-time, even with the addition of SET COVERAGE logging.

Getting back to the client with the slow performing feature in your application, you can now SET COVERAGE TO C:\temp\CoverageFile.TXT to start logging and SET COVERAGE TO to stop logging. Remember, just like in the development environment, these files can get large quickly. You might want to consider carefully placing the command to begin and stop logging. Your customers do not have the Visual FoxPro debugger to interactively control logging. Chances are very good you will need to send your client a build with strategically placed SET COVERAGE commands to turn logging on and off. The user runs the code and generates the logs. Another approach might include a combination of a local table and event binding strategy to start and stop the logging. After the logs are generated, the user compresses the files with WinZip or another compression tool and either e-mails the file or loads it to a FTP site where you can download it.

Unfortunately, nothing like this is free in our world. There is an issue with the logs recorded in the production environment. It shows the source code files in the log with a full path to the production directory where the EXE is loaded, plus the development directories to the source code file (as it is stored inside the application executable). If the source code is not in the directory tree directly below the project (like a common folder), the path is relative to the EXE folder. This means the coverage logs your clients send to you have paths different from the full source code path you have for your project. Here is an example. The first executable was run and logged in the project directory (see Figure 1). The second log was generated from a separate temporary “production” directory (see Figure 2).

What happens when your user sends you coverage logs with improper paths? You are prompted numerous times to locate each of the source code files recorded in the log entries when you start the Coverage Profiler. If your project code is anything like ours, you probably have numerous class libraries, programs, reports, and so forth scattered in various directories. You will spend time either locating the files, or ignoring the messages and not running the Coverage Profiler for the log. Is there any way around this? Sure, you can write a tool that preprocesses the coverage log and substitutes the production paths with the correct project source code path. Sound like fun? Sure, you are a Fox developer and quite accustomed to writing your own tools.

Included in the Developer Downloads for this chapter available from www.hentzenwerke.com is a form called CoverageLogPathFixer.scx/sct. This tool presents a user interface to help facilitate the path correction process between production and development directory structures.

Figure 1. The path collected in a coverage log run from the project root source directory records the proper path to the source code.

Figure 2. The paths collected in a coverage log run from the production directory do not map to the source code.

The Coverage Log Path Fixer (Figure 3) is very simplistic. Select the production coverage log file sent to you by your customer, either by entering the path and file name
in the text box or by using the button to select the file name. Selecting the file triggers a
few features:

· The tool creates a name for the fixed coverage log file by using the same name as the production log and adding “_fixed” to the end of the file name stem.

· It reads the production log file into a cursor.

· It enables the Edit Fix file button.

· It evaluates the cursor and presents the unique production paths in the
second grid.

Select each of the unique production paths in the grid one-by-one. You can type in the development path or use the Select Directory button to the right of the grid to select the folder via the GETDIR() dialog. Each production path must have a development path assigned; if not a message displays when you try to fix the paths. The folders must exist. Once the directories are selected, press the Fix Paths button. If the file is created and the paths fixed, the Edit Fixed File button is enabled and the Fix Paths button is disabled. You can use the Edit Fixed File button to review the new file.

Figure 3. The Coverage Log Path Fixer is a tool we developed to facilitate
the correction of production paths to the source code paths on your
development machine.

Once the fixed file is created, start the Coverage Profiler to test the new file. The Coverage Profiler should open with the timings and coverage recorded in production, but it is compared to the source code on your development machine.

When you compare the coverage logs to the source code, you need to have the exact source code used to generate the production executable. Chances are, if you have an active client project, your source code has changes in the process of being readied for a future deployment. You need to archive the source code if you intend to use the coverage logging in production.

Improved performance and support detecting
Terminal Server

Visual FoxPro 9 automatically adds to each EXE support for running better in a Terminal Server session. The build process now includes the /TSAWARE flag as a new LINK command for your Visual FoxPro executable file. You do not have to do anything additional; this is automatically built into the executable each time you build the project into an EXE. This internal flag is used by the run-time loader to prevent the loading of unnecessary dynamic-link library (DLL) files, which impacts the performance of your applications.

If you read this chapter during the VFP 9 beta, you read about the use of EditBin.EXE to turn the /TSAWARE flag off if your application opens an INI file. This issue is no longer valid and there is no need to run EditBin.EXE
for VFP 9.

You can view the change in the EXE only in a hex editor (Figure 4). We are not recommending this, but some developers might be curious about the change. Our research shows the /TSAWARE flag is at offset 14F (set to 0x8000).

Figure 4. You can use the HexEdit tool that ships with Visual FoxPro to view the /TSAWARE setting in the EXE you build.

According to the Fox Team, you can use the .NET 2003 Visual C Link command to reveal the setting. The Terminal Server Aware setting is found under the Optional Header Values section. The command is run using the following syntax:

link /dump /headers WlcNewDialog.exe

Updated Dr. Watson error reporting to 2.0

Dr. Watson is the applet all users hate to see displayed (see Figure 5) as their program crashes and prepares to send some information to Microsoft. The applet has improved and is installed to capture errors when Visual FoxPro 9 crashes or when your application crashes with a “C5” or General Protection Fault (GPF) type error. The new and improved applet does a better job collecting important information Microsoft uses to find problem code in Visual FoxPro. Dr. Watson 2.0 can also record your crashes when you are not connected to the Internet, and then report them back to Microsoft when you re-establish your connection.

Figure 5. Dr. Watson Error reporting provides some new features with respect to errors sent to Microsoft.

The new Dr. Watson applet also lets you view the information sent to Microsoft. You access this information using the click here hyperlink. A dialog with the error signature and several paragraphs of privacy information displays (see Figure 6). This dialog has a View the contents of the error report hyperlink. Clicking the hyperlink displays the details of the error report (see Figure 7).

Figure 6. The details of what Dr. Watson sends to Microsoft are prefixed with a privacy dialog (maybe Dr. Watson is an attorney).

Figure 7. The Error Report Contents dialog is provided so you can review the information and verbose details sent to Microsoft for their review.

If you read this chapter during the Visual FoxPro 9 beta, you read about non-critical errors being recorded in addition to the critical errors. This is not included in the shipping product.

If you think these error reports go into a bit bucket, fear not. The Product Support Services (PSS) team on the Fox Team reviews all the submissions looking for ways to improve the stability of Visual FoxPro.

New configuration settings

You have a new Config.FPW setting to help control the amount of memory dedicated to programs. The PROGCACHE is available to determine the amount of internal program cache Visual FoxPro applications, the development IDE, or a MTDLL COM Server allocate when they are started. When Visual FoxPro reaches the memory limits established by the setting, it flushes allocated memory to free memory.

PROGCACHE was created primarily for multithreaded DLL COM servers. MTDLL COM Servers often have many threads created on a single server and this configuration setting provides you better control of memory usage.

The setting is the number of pages of memory you want allocated. Each page is equivalent to 64K of memory. You can set the PROGCACHE from 1 to 65,000 (positive or negative) to designate how much memory is allocated. If you specify zero, no program cache is used and VFP uses dynamic memory allocation determined by the operating system. If you set the PROGCACHE to a negative number, VFP uses dynamic memory allocation, but is limited to the number of memory pages you specified. The default setting is 144 (over 9 megabytes) for single-threaded EXEs and the VFP IDE, and -2 (128 kilobytes) for a multi-threaded DLL. The VFP OLE DB Provider does not use this setting because it uses dynamic memory allocation.

It is possible that Visual FoxPro cannot free enough memory. In this case your error handler will be exercised when error 1202 is generated (Program is too large). You can adjust the PROGCACHE setting to prevent this error from occurring.

You can call SYS(3065) to determine the current PROGCACHE setting. This is not something you typically do in a production application, but CLEAR PROGRAM will attempt to clear unreferenced code regardless of this setting.

FoxRun.PIF change

The FoxRun.PIF file is moved from the Visual FoxPro root folder to the Tools\FoxRun folder. It should reside in the same folder as your executable when deployed. This file is used to control which operating system ComSpec is used by the RUN command. If you do not deploy a FoxRun.PIF file, and your application executes the RUN command, the current behavior of VFP is to use the command interpreter shell program specified by the operating system ComSpec environment variable.

You can determine the operating ComSpec setting by shelling out to the DOS command window, and typing in SET. This will list all the environment variables. You can also use the My Computer properties dialog. On the Advanced page is a button which displays the Environment Variables dialog (see Figure 8).

Figure 8. In Windows XP you can review and set the ComSpec environment variable from the My Computer properties Advanced page.

FoxRun.PIF is still configured to use Command.COM. This is different from the VFP 9 beta, in case you were testing your applications with beta code.

You should be aware of some differences when deciding which command interpreter you want to deploy with your applications. Command.COM is the single-threaded, 16-bit equivalent of MS-DOS embedded in Windows. On NT-based systems, Command.COM starts a basic DOS window in a “virtual DOS machine.” The command line does not support long file names. This means you need to address the folders and file names with the 8.3 file naming standard. Folder names longer than eight characters require the tilde plus the number when you change folders using the change directory (CD) command. We have read you cannot run 32-bit applications from the Command.COM window; however, we have run a 32-bit application, like Excel on Windows XP. The difference is the command line is not available until the program is closed, demonstrating the single-threaded nature of Command.COM.

Cmd.EXE is the Windows 32-bit command interpreter, which launches the multi-threaded Windows NT command shell. You get long file names, an extended batch language, file and directory name completion, native command history, and access to NT services and security. Under Windows NT/2000, the command line is limited to 2047 characters. Under Windows XP, the command line is limited to 8191 characters.

One of the differences that might catch you off guard is the difference in the location of the temporary folder. If the application you are running uses the RUN command to look for a temporary file your application created in the temporary folder, the location could be different if you use Command.com as the interpreter in FoxRun.PIF.

InstallShield Express FoxPro Limited Edition

The version of InstallShield Express – Visual FoxPro Limited Edition (ISX LE) has been upgraded to version 5.0 from version 3.5 Service Pack 4 by InstallShield. This means an improved and enhanced interface, some additional features that may benefit your deployment packages, and the same limitations implemented in the version shipped with Visual FoxPro 8. The limited edition remains one major version behind the flagship InstallShield X Express offered directly from InstallShield (purchased by Macrovision).

Among the features still disabled in ISX LE are Custom Actions, Dynamic File Linking, Globalization, and File Dependency Scanning. Although you can get along without these and the other disabled features, you may wish you had them if you do a lot of setup development. Here is a list of the features disabled in ISX LE shipping with Visual FoxPro 9 compared to the full version of ISX v5.0.

· Support for Visual Studio .NET (this refers to the integration with Visual Studio .NET, not the deployment of the .NET framework)

· Billboards

· Custom Actions

· Dynamic File Linking

· Environment Variables

· Globalization

· Import and Export String Tables

· Objects

· Scanning Wizards

· Setup Files

· Text and Messages

· System Software Requirements (like Acrobat, Internet Explorer, MDAC)—this is a new limitation with ISX LE shipping with Visual FoxPro 9, as this feature was not available in the version shipped with Visual FoxPro 8.

· IIS Virtual Directories and Component Services—this is a new limitation with ISX LE shipping with Visual FoxPro 9, as this feature was not available in the version shipped with Visual FoxPro 8.

· Web Deployment

Installation

The first significant difference you may notice if you have a previous version of InstallShield Express (v4.0 or earlier, limited or not) installed is the fact it is still installed when you install ISX LE v5.0. Until this release, InstallShield automatically uninstalled previous versions and replaced them with the current version. This means you can continue using the older version with older installs until you choose to update the installation project.

One word of caution: if the full version of ISX v5.0 is already installed on your machine, installing ISX LE v5.0 will render the full version inoperable. It doesn’t uninstall it, just changes the registry keys to point at ISX LE.

When you installed the ISX LE shipped with Visual FoxPro 8, it removed the version
you installed with Visual FoxPro 7 (or the full version purchased from InstallShield) and forced you to update the project files. In most cases this was not a problem, but as a
developer approaching a deadline, you might not feel confident in releasing with new deployment software until you have a chance to test it. This is a significant advantage from our perspective.

Project Assistant

The second significant difference is the Project Assistant replaces the Project Wizard (Figure 9). Conceptually they are the same, assisting you with initial selections for your installation project, but the Project Assistant is better organized, includes a few more property settings, and is re-entrant.

There is no requirement to use the Project Assistant to create a new InstallShield project, but it can speed up the initial project selections in a sequence different than stepping through the choices in the Installation Designer (treeview of the steps processed in both version 3.5 and version 5.0). You answer a few questions, make a few selections, and the properties for the project fill in according to your choices.

If you do not like the Project Assistant you can remove it from the user interface by unselecting the menu item View | Project Assistant.

Figure 9. The Project Assistant provides logical and rapid access to the common property settings for your InstallShield project.

Once the Project Assistant is complete, you will find yourself going to the Installation Designer to make additional settings and customizing the installation package even further.

Redistributable Downloader

InstallShield has numerous merge modules available on their support Web site. All you have to do is go to the site (it is open even to developers who use other Windows Installer routines such as Wise for Windows Installer), pick the merge modules you want to use with ISX LE and install them after downloading. This version of InstallShield Express Limited Edition has a built-in wizard called the Redistributable Downloader (see Figures 10 and 11) that downloads and installs merge modules, third-party redistributables, and other files for you to use in your InstallShield Express Limited Edition projects.

The process is very straightforward. Start the wizard from the Tools | Redistributable Downloader menu. The first step is the introduction page, the second step is the merge module selection page, and the third page shows the progress of the download.

Figure 10. The second step of the InstallShield Redistributable Downloader wizard presents a list of merge modules you can download from the InstallShield Web site.

Figure 11. The third step of the InstallShield Redistributable Downloader wizard shows the progress of downloading the selected merge modules.

DemoShield Browser Wizard

The DemoShield Browser Wizard is, well, demo-ware. DemoShield is a separate product available for purchase from InstallShield assisting you in the creation of professional multimedia material you can include on the installation CD-ROM. This multimedia material can showcase your application, provide interactive demonstrations and simulations of the features (via animated screen shots), and provide additional contact information such as a link to your Web site. You can use the DemoShield Screen Capture Wizard to capture the
screens, and then add in your own voiceovers describing the functionality as well as
captions and callouts.

There is a 30-day evaluation of DemoShield included in the installation package. The wizard steps you through the entire process of creating the DemoShield database, but unless you purchase a separate license, it is not a good use of your time. More details on DemoShield are available at http://www.installshield.com/ds/.

Help

The new Help file merges the InstallShield Express and Windows Installer Help files into one file. Naturally, the information is updated to conform to the current feature set.

Product functionality changes

There are numerous enhancements between the limited edition shipped with Visual FoxPro 8 and 9. The following sections address only the changes. They do not describe in detail how to use the new features in the limited edition, only why you might find the functionality useful in your deployments.

Features

The Features functionality exposes the Key Name (read-only). This is the MSI Key used internally in the MSI database to represent the feature. If you select to purchase the full version of InstallShield Express, according to the documentation, the Key Name can be used in Custom Actions, but is read-only even in the full version.

Files

The Files destination folder pane has some new predefined folders in the list including [ALLUSERSPROFILE] and [USERPROFILE]. The InstallShield development team also removed the [COMMONFILES64FOLDER], [PROGRAMFILES64FOLDER], and [SYSTEM64FOLDER] predefined folders. If you used any of the removed destination folders, you need to verify that upgrading existing InstallShield project files converts the folders for any files you directed to these obsolete directories.

Redistributables

The Objects/Merge Modules step is renamed the Redistributables step. Two of the challenges Visual FoxPro developers face when assembling a deployment package are determining which merge modules to include in the package and locating the merge modules available. Prior to the new version, to determine the files included in a merge module you needed to use a product like the Orca MSI table editor from Microsoft, or some Microsoft Installer tool that could read the merge module and determine what was inside. ISE LE v5.0 provides a view inside the merge modules we think you will find very useful.

Dependencies and the list of files included in the merge module display in the Description pane (lower left pane to the right of the treeview – see Figure 12). This feature was introduced in the full version of InstallShield Express v4.0, but because Visual FoxPro developers did not get a limited edition of this version, it is new in version 5.0 of the limited edition. This is very useful for confirming a particular merge module includes the file(s) you want to install. The tool shows the Microsoft Visual FoxPro 9 Runtime Libraries merge module installs three Visual FoxPro run-time files (see Figure 12) and is dependent on the Microsoft C Runtime Library 7.1 and GDI Plus Redist modules.

Figure 12. The Redistributables step shows additional information about the merge module including dependencies and what files are included for distribution when you select the module.

Earlier in the chapter (see “Redistributable Downloader”) we covered the Redistributable Downloader and how you can download new or updated merge modules. The Redistributables feature helps developers locate merge modules available for download. The Redistributables view shows the list of merge modules; this list now shows different icons to indicate the status of merge modules and objects (see Figure 13). Table 1 details the various settings.

Table 1. The Redistributables view now shows icons in front of the merge module or object name. These icons have the following status.

Icon	Status
	This object is installed on your computer
	This object is not installed, but is available for download.
	This object is installed on your computer, but is an old version. A new version is available for download.
	This merge module is installed on your computer.
	This merge module is not installed, but is available for download.
	This merge module is on your computer, but is an old version. A new version is available for download.

Figure 13. The merge module and object status icons display in the InstallShield Objects/Merge Modules pane on the Redistributables page.

The advantage for developers is two-fold: you can tell what merge modules/objects you do not have, but are available for download, and you can find out which modules/objects you do have, but are obsolete or out-of-date.

Shortcuts/Folders

The Shortcuts/Folders step has a new option to create an uninstall shortcut. This allows your users to uninstall the application without accessing the Windows Control Panel Add/Remove Programs applet. The new Uninstall Shortcut feature is not easy to find; it is only available on a shortcut menu when you select a folder in the shortcut treeview. You can set properties for the Description, Arguments to MsiExec.exe when running the uninstall, the Target (this is the uninstall program, defaulting to MsiExec.exe), Icon File and Icon Index, Run (normal, maximized, or minimized window), the Working Directory, a Hot Key, Comments, and which of your defined Features this shortcut is associated with (this is only available to change for Uninstall shortcuts, not regular or advertised shortcuts).

Cut/copy/paste options have been added to shortcut menus for custom folders
and shortcuts.

ODBC Resources

InstallShield moved the ODBC attributes to the upper right pane, and Associated Features to the lower center pane. This is a purely cosmetic change. Additional attributes for the SQL Server and Visual FoxPro DSNs include Database destination, Permanent, and Driver Description. In general, reviewing other data sources, most have additional properties available in the new version of ISX LE.

Dialogs

The Setup Complete Success dialog found under the Dialogs step has a new option to Use Update Service User Interface. This functionality is off by default and can only be turned on if the Update Service feature is turned on under step five, Enable Automatic Updates. One note of caution: if you enable the update service, you disable the Show Launch Program and Show ReadMe options on this same dialog.

Enable Automatic Updates

If you are using the InstallShield Update Service, there is a new option where you can specify a self-hosting site via the Host property. If you are not familiar with the Automatic Updates functionality, it is a product and a service directly offered by InstallShield. It works on the same premise as Windows Update, automatically downloading and installing new versions of your applications. This service automates the entire update process from notifying your customers a new version of your application is available, all the way through the process of installation. This service eliminates the need for you to burn CD-ROMs and distribute them to the users, or instructing your customers to download and install the update from a Web site. The pricing for this service depends on the volume of customers downloading the updates. More information is available at http://www.installshield.com/products/updateservice/.

Requirements

InstallShield Express version 5 introduces Windows 2003 Server to the list of selectable operating systems required/supported for your deployment package.

One of the shortcomings of using one of the older versions of InstallShield Express is the operating system list is usually outdated. If you do not have a complete list of operating systems, you cannot use the Operating System Requirements feature to eliminate unsupported operating systems because doing so also eliminates newer operating systems.

In the case of ISX LE shipped with VFP 7, you quickly lost the ability to use this feature because Windows XP was not on the list. The version of ISX LE shipped with VFP 8 does
not have Windows 2003 Server on the list of operating systems you can deploy your application on. Therefore, to really be current, you need to use InstallShield Express v5.0 (limited edition or full edition), or InstallShield X Express (only available as the full version). The other option is not to restrict installations based on the operating system the user has installed on the target computer.

Build Your Release

There are a couple of new features with respect to building the installation package: DemoShield file names, support for the .NET Framework, and a new way to review the log files generated by the build.

Each of the physical media builds (CD-ROM, DVD, or Custom) has a new property called Demo File Name. This feature is not available for diskette, Web deployments, or SingleImage releases. The Demo File Name allows you to specify a fully qualified path to a DemoShield Browser Database file (DBD extension). The DemoShield Browser Database can be created by selecting the DemoShield Browser Wizard option on the Project menu (described earlier in this chapter in the section called “DemoShield Browser Wizard.”) This wizard steps you through the various selections necessary to build the DBD file and sets the Demo File Name property for the build.

The .NET Framework Location properties are new to this version of ISX LE. Visual FoxPro developers typically do not release the .NET framework with their deployment packages. The main reason this is included is because the Limited Edition is also distributed with Borland’s Delphi, C++ Builder and C# Builder.

The log files generated by the build are available under the media type (see Figure 14) if you drill down in the Builds treeview to the Logs node. This feature was available in the previous version of ISX LE. The new feature with respect to the log is the availability of a hyperlink in the build output at the end of the listing, right after the counts for error and warning for the build. Click the hyperlink to open the log in the application associated to the TXT extension (by default, Notepad). This saves you from resizing the output pane in InstallShield Express, or the need to drill through the build treeview to get access to the current log.

Menus and toolbars

The menu has several minor changes to incorporate new features and expose existing functionality differently:

· The Project menu has a DemoShield Browser Wizard option, used to create a DemoShield Browser Database.

· The Build menu has Quick Build (not available in ISX LE) and Uninstall options.

· The Tools menu has Create Quick Patch (not available in ISX LE) and Redistributable Downloader options (see Figure 10).

· The Help menu has links to the InstallShield Support Web site, InstallShield Community (online help forums with peer-to-peer support), and InstallShield Home Page.

The main toolbar has a new button to run the Uninstall functionality.

Figure 14. A history of the build log files is in the treeview under the build type. The current log file is accessible through the hyperlink at the end of the build output.

Tools Option dialog

The Tools Option dialog has new functionality as well as some removed functionality. The settings made on this dialog are general settings used for all installation projects.

The General page has a new option to stop the build process when the first error occurs. This is great for large projects when a build could take 10 minutes. Allowing it to stop when the error occurs could save several minutes per build when you first set up the project.

Merge Module locations have moved from the File Locations page to the new Merge Module Options page.

The all-new Preferences page has two options for you to configure: Uninstall before installing, and Reload last opened project on startup. It is not uncommon for a developer to work repeatedly with the same InstallShield Express project file, so selecting this option saves you time opening the project via the menu. The option is not new, just the location where you set it is new. Previously this was set on the Installshield Today page in version 3.5.

Merge Module search behavior options on the Merge Module Options page is a great feature. If you add a file to the project, ISX searches all the installed merge modules to see if the file is available in the merge module. You have options to define how ISX determines if it uses the merge module or the file you included:

· Matching files must have the same version

· Matching files must have the same destination

The all-new Quality page allows you to participate in an InstallShield survey. This is optional; you select whether you want to spend the time helping InstallShield improve
their product.

The InstallShield developers removed the option to select when updates are processed (when launched or never) on the InstallShield Updates page.

The .NET page is completely new (.NET was not supported in the previous version). You use this page only if you leverage ISX LE for any .NET releases you make. This page has settings for the location of the .NET product files and the ability to determine how the .NET Scan at Build property is set. The all-new Files View page allows you to select the columns displayed on the Files view.

InstallShield X Express

As noted earlier in this chapter, the limited edition is one version behind the flagship InstallShield X Express product. If you find the limitations of the version included with Visual FoxPro a serious problem for your installation packages, you may want to consider getting the full version.

If you want to compare the features available in the ISX LE v5.0 and the full version of InstallShield X Express (Standard, Professional, and Premier), check out the information on the InstallShield Web site at: http://www.installshield.com/products/x/express/features/le_compare.asp

Summary

The Fox Team at Microsoft and the InstallShield team have both added a number of features
to make deployment and support of your applications easier. We think you will agree that
the changes will save you time and give your installation setups a more professional and polished look.

Updates and corrections for this chapter can be found on Hentzenwerke’s website, www.hentzenwerke.com. Click “Catalog” and navigate to the page for this book.