General implementation issues

The following sections address some specific issues with traditional workstation and LAN implementations .

Security

Installing on workstations connected to LANs introduces the opportunity for network security in addition to the basic operating system security found on Windows NT, 2000, and XP. Windows 95, 98, and ME do not have the same security features, but can interact with network security.

If the user is installing any components for the application, make sure they have administrative access to the machine. ActiveX controls absolutely need to be installed on the workstation, not on the server. Most developers install the Visual FoxPro runtime files (including the GDI and Visual C++ runtimes ) on the local workstations regardless if the application and data are loaded on a server machine.

The user who installs the application and data on the server needs proper access to write these files on the server. Small businesses might not have a sophisticated security scheme in place, but larger companies with internal network support or contracted network support typically do have security tightened down so the users cannot harm company assets located on the server.

Installation to new folders and new drives might require the implementation of additional security so users have the rights to access these folders and files on the server. It is best to check into this issue well before implementation, but we recommend adding a step to the process and installation instructions to address this potential problem.

Executables

Executable files come in many flavors with Visual FoxPro. You can deploy an EXE (with supporting runtimes), one or more APPs or FXPs called from a master EXE or run within a copy of Visual FoxPro, or you can deploy the source code directly. Table 2 describes the advantages and disadvantages of each type of executable.

Table 2. Advantages and disadvantage of executable deployment.

Executable	Advantage	Disadvantage
EXE	Royalty free runtimes and fewer files to distribute than other options	Application cannot be running when updating new executable.
APP / FXP	Developer can bundle features in an application and update parts of the overall solution. Easier to copy one APP or FXP file into production folder because less chance someone is using it.	Requires copy of VFP for each user or a master EXE you distribute with APPs. More files to track during deployment, better planning as to what APP or FXP needs to be deployed during an update, more complexity for developer as to what feature is in what executable.
Source code	More granular control of what features are updated in the release.	Requires copy of VFP for each user or a master EXE you distribute with APPs. Easy for another developer to ‚“ borrow ‚½ intellectual property, even more files to keep track of than the APP or EXE option.

One of the more frequently posted questions on the various support forums (see Appendix F, ‚“Support Forums ‚½) is: ‚“Why does my application start on the customer ‚ s computer, flash for a second, and then shut down? ‚½ The application works fine in the development environment. It is a common mistake developers make the first time they deploy a Visual FoxPro application. They do not know to add the all-important READ EVENTS in the start up code for the application. The good thing, it is typically the last time they forget to add the wait state to their main program or main application object and it is an easy problem to solve.

The often-debated architectural question is where to locate the executables. Do you locate them on the server or workstation? Locating them on the server centralizes the files and makes the updates simpler because there is only one location to copy or install the new executables. It also takes longer to load the executables each time they are run because it has to pull the EXE files across the network wire. In a LAN, the impact is minimal if your customer is running a super fast LAN and has it designed in an optimal manner. What if it is not? What if the network is really Wide Area Network (WAN) and you are pulling down the executables across hundreds of miles of wire? Even with super fast connections like a T1 line, this could severely hamper the users. The alternative is to load the EXEs on the workstation. No problem, we have professional install programs to do this. In a small company it might not be a problem to install the EXE on 5 or 10 computers, but what if there are dozens in various buildings on a campus? What if there are several locations dispersed over a larger geographic area? Is there a solution that is easy to deploy and maintain?

Many developers have faced this problem head on with a distributed mechanism that allows them to deploy the EXE in a centralized folder and have a launcher program located on the workstation. This launcher program checks to see if there is a different or updated program located on the server and copies it down before launching the application. Some launcher programs check each time, some check on a scheduled basis, some validate by file dates and sizes, and others check a registration file to see if a different version should be downloaded.

On The Web ‚  

There is more information on launcher/loader programs on Steven Black ‚ s Wiki at http://fox.wikis.com/wc.dll?Wiki~LoaderProgram~VFP .

On The Web ‚  

We included the Launcher executable source code used by White Light Computing, Inc. in the chapter downloads. This handy utility was inspired by code published by Nick Neklioudov many years ago and posted on the UniversalThread. The file with the source code is in the chapter ‚ s LAUNCHER folder. A ReadMe file is included with instructions on how to run and configure this program.

The sample Launcher program included with this chapter has the following steps:

• Opens up an INI configuration file (to read the source file directory, the target file directory, which files are copied , and which executable is launched)

• Reads in the list of files to copy from source directory to target directory.

• Determines which executable (if more than one copied) is the one launched.

• Determines if the file is different in the source directory for the same file in the target directory, which is determined by the file date/time and the file byte size of each set of files.

• Copies the files from the source directory to the target directory if the file does not exist in the target folder, or the date/time or byte size of the files differ .

• Copies associated files for the file specified in the INI file. For example, if you specify the database container file (DBC), the database container index (DCX), and memo (DCT) files are copied as well because these files work as a set. The same happens if you specify forms, reports , menus , and class libraries.

• Launches the specified executable if one is specified in the files list.

• Writes the log file.

The Launcher program performs some basic logging of activity as it copies the files from the source directory to the target directory, and for capturing error details if any occur. The log is displayed in development for testing purposes and retained in text format during development and runtime executions.

Features you might want to customize for this tool include compiling a version for each application you distribute so the Launcher executable icon seen in Windows Explorer matches the icon used for the application. You might only want newer files copied down from the source directory instead of different files (older or newer). We like checking for a different file to allow an older executable to be reloaded into production if we have a major problem with a newer version. The last point of interest is copying down updated versions of DLLs or COM EXEs, which might require the registration of the component (see ‚“ActiveX controls and COM objects ‚½ section in this chapter for more details).

Note ‚  

Doug Hennig wrote a two-part article in the September and October 2000 issues of FoxTalk on how developers can update applications over the Internet. Doug details how the application can act as the ‚“loader ‚½ by FTPing a ZIP file from a Web server, and then spawns a process that unzips the downloaded file, kills the main executable, and copies the new executable in place.

Data

The Visual FoxPro data side of the deployment is generally ‚“easier ‚½ to deploy. We copy a set of files to a folder or set of folders on a computer. There is no need to manage a database server, or worry about connection strings and/or ODBC data source names . There are no extra tools to deploy and run database scripts and verify security settings. Now proponents of client server technology might not see these issues as drawbacks and we are not indicating them as negatives , rather we are noting additional support issues a developer can ignore if they are deploying Visual FoxPro data in a traditional setting.

There are architectural choices you make as you are developing your applications that impact deployment. Are you using a database container, more than one database container, free tables (no database container), or a combination? Some developers have worked with free tables since the beginning of time and see the database container as overhead. Other developers like the advantages of long field names and properties like captions, default values, transactions, engine level referential integrity, and deploy only database-contained tables. Many developers deploy a combination of database contained tables and free tables (mostly used for metadata).

One of the techniques we have been using for years is deploying at least two database containers, one for the application tables and the other for local views. We know developers who take this even further by separating the view databases into one for data maintenance (used in data entry forms) and one for reporting views (queries for reports). The advantages are numerous . When you open a view, Visual FoxPro temporarily locks the database container while it extracts the view definition to guarantee it gets the current definition. If multiple instances of the application both attempt to open a view at the exact same moment, one of the applications could experience an error 1709, ‚“Database object is being used by someone else. ‚½ It is one of those errors your application might never trigger, but it is an error many developers see when their application hits 40 to 60 or more users. This number depends on the number of views accessed by your application and the intensity of use by the users. By keeping the views separate, you can keep a copy of the view database container on the workstation. A best practice is to make sure all views definitions include the database name in front of the table name in the FROM clause so this eliminates the problem of finding the database with the tables. Some developers even compile the view database into the executable to automatically get a local copy because the executable is loaded into memory on the workstation.

Note ‚  

The view contention problem is discussed in detail on Steven Black ‚ s Fox Wiki ( http://fox.wikis.com/wc.dll?Wiki~CreatingDBCforViews~VFP ).

There are only three general issues of concern in deploying Visual FoxPro data, regardless of the database architecture discussed. First, the tables need to be in the same relative path to the database container (DBC) as you have them on your development machine. If you have the DBC and all the tables in one folder, they need to be deployed in the same folder. The folder can be a different name on the target computer. If the data base container is in a separate folder from the tables, the same relative folder structure, including the name of the relative folders, must be mirrored on the target machine (see Figure 3 ). As an example: if some of the tables are in a Data folder and System folder and these folders are directly below the folder where the database container is located, you need to deploy the Data and System folders on the target computer underneath the folder with the database container.

Figure 3. The database container files must be deployed to the same relative folder structure as you have on your development machine.

The second issue is the application knows where to find the data. Some developers keep the database container in the same folder as the executable; some developers prefer to put the DBC in a subfolder underneath the executable folder. Some clients prefer data reside on a different drive than the executables; some prefer to have the data on different servers or computers. No matter where the data ends up in the target environment, the application needs to be able to find it. You can hard code the OPEN DATABASE and the USE statements, which is dangerous, or you can use the Windows Registry to store the location, a text file like an INI, or even a free table containing configuration information. The important point in this discussion is to understand the target environment and be flexible enough to handle the various possibilities the clients and possibly their internal technical staff might require.

Thirdly, you need to make sure you are deploying all the files. These files include the three database container files (DBC/DCT/DCX), tables (DBF), indexes (CDX/IDX), and memo files (FPT). One missed index file or memo file and your application has problems opening tables. Tables will not open unless you have the correct database container because the database container contains structural information about the tables, columns in the tables, indexes, etc.

One more decision you need to make is when and how to deploy the data and structural changes. If you deploy it programmatically (either through a custom program or initiating a Stonefield Database Toolkit via the Update method) you should provide a post-installation executable or make it part of the application startup process. If you deploy the table and/or database container, you have to configure the installation tool to handle the tables and not overwrite existing data. You might want to consider a separate installation for the data because it is usually a one-time deal. We are not talking about the metadata, rather the tables, indexes, and memo files. The trade off is keeping track of, updating, and deploying two separate installation routines for new installations. Your updates become simpler because you do not need to send the data install, just the metadata (DBC(s), DBCX metadata, framework metadata), which is already part of the primary installation package.

Configuration file (FPW)

CONFIG.FPW can be used to configure both the Visual FoxPro development environment and your custom applications. For custom applications, you can control any of the SET functions as well as improve the performance of the application startup by setting a number of Visual FoxPro system memory variables to the null string ( SPACE(0) ).

Listing 1. Sample CONFIG.FPW enhanced for performance.

 SCREEN = OFF  ALLOWEXTERNAL = ON  _BROWSER = ""  _BUILDER = ""  _FOXREF = ""  _CONVERTER = ""  _COVERAGE  _GALLERY = ""  _GENGRAPH = ""  _GENHTML = ""  _GENMENU = ""  _GENPD = ""  _GENSCRN = ""  _GENXTAB = ""  _TASKPANE = ""  _TOOLBOX = ""  _TRANSPORT = ""  _WIZARD = ""  

 

You may need to consider different codepages depending on where your applications run. If this is the case you can use CONFIG.FPW to adjust the default codepage with CODEPAGE = nnnn , where nnnn is the codepage number. If you do not want to use a copy of the FoxUser.dbf resource file, you can include a RESOURCE = OFF in the C ^ONFIG . ^FPW file.

The next question is how do you ship the CONFIG.FPW file? Do you deploy the file external from the executable, inside the executable, or both? Both? Yes, Visual FoxPro 8 allows both an internal CONFIG.FPW and an external file. To include the file inside the executable you mark it included in project. Visual FoxPro reads this file first if it is included inside the executable. To include both you need the following command in the internal configuration file: ALLOWEXTERNAL = ON .

Which way is better? As usual, it depends on your needs. If you are deploying an application based on top-level forms, you need to include the file in the executable with the SCREEN = OFF so the main Visual FoxPro frame never displays. You can use this for applications not based on top-level forms as well, just make sure to have _screen.Visible = .T. in the start up code of the application. If your application needs flexible configuration options for each computer, an external file might be optimal. We prefer the internal file option with ALLOWEXTERNAL because it leaves us the option to have additional settings if we need them. If you are using Visual FoxPro 7 or earlier, you have to make the choice. In this scenario, we used the internal because it is one less file to deploy and we did not display the application main window until the application setup process was complete and the application was ready to log in. If you use an internal file and display the location in your application using the FULLPATH(SYS(2019)) command, the file displayed is the current directory, plus the relative path as it is on your development machine. For instance, if you use a CONFIG.FPW file in the Text directory underneath the project folder, the file name displayed is the location of the executable, plus TEXT\CONFIG.FPW (see Figure 4 ).

Figure 4. The application ‚ s About form is one place to put details such as where the temporary files are directed.

MVCOUNT sets the maximum number of variables your application can maintain and defaults to 16,384 in Visual FoxPro 8. We used to set this to 2048 for our applications. Because the default is higher we no longer include this setting in our configuration file. If you are using a different version of Visual FoxPro or need more than the current default, you might want to give this setting some consideration.

If your deployments include accessing the application via Windows Terminal Server or Citrix client you might want to include BITMAP = OFF to improve performance. This setting specifies whether Visual FoxPro first writes screen or form updates to an off-screen bitmap, and then performs a bit block transfer to the actual screen. The off-screen bitmaps do consume a lot of memory so it is better to turn this off when using Terminal Services. There are other issues to be aware of with this setting. If you write directly to a form using the Line method you must set BITMAP = ON (this is the default setting). This setting is an excellent candidate for an external configuration file if your application might run on both a Terminal Services environment and ordinary workstation. Alternatively you can use the SYS(602) command in your application to control the state of the off-screen bitmap usage.

Temporary files

Visual FoxPro creates files in the temporary folder when your application performs queries, caches indexes and programs, or edit files. The temporary files are located in the user ‚ s Windows temporary file folder at runtime unless you direct the executable with the TMPFILES setting in the CONFIG.FPW file. Performance is always king. Managing the location of the Visual FoxPro temporary files can be the difference in many situations.

We have seen applications with the temporary files folder on the server because this is where all personal files are directed for the office, based on direction from the network administrator. The performance was horrible for SQL Selects because the temporary cursors were created by pulling the data down from the tables off the server and moving the data back to the server into the temporary (TMP) files. The same goes for caching index files. This is why we recommend directing the files to the local workstation. If the Windows temporary file folder is on the local workstation, you do not need to make any changes. If these files are directed to a slow drive or a network drive, you can use the TMPFILES directive to direct the files to a better directory.

You can see where the files are being directed by displaying FULLPATH(SYS(2023)) somewhere in your application. We include this information on our About screen (see Figure 4) in case we get a support call noting slow performance.

Other configuration settings and Registry

Developers also have other various techniques and storage mechanisms for application level settings and user-defined settings. There are different ways to store this information such as free and database-contained DBF files, INI files, and the Windows Registry.

Custom DBF files are easy to manipulate and a format FoxPro developers work with all the time. These files can be deployed in the application directory and are commonly distributed in a Metadata, System, or Settings folder. The folder they are distributed to is often found underneath the application folder and is hard-coded into the application. This might sound inflexible , but it is the simplified design developers can rely on and work with if deployed properly. InstaFox is the only installer tool we have experience with that can manipulate DBF contents directly. With other installers , you need a post-install executable or functionality in the application to update the contents of the DBF if it is necessary during deployment.

Flat text INI files are easy for end users and developers to edit in a tool like NotePad. Applications need code to parse the settings from the file. This is not difficult and most frameworks provide support for this functionality. The key with deployment is making sure the files are installed and the applications know where to locate the files. Most often, these files are installed in the application root directory. Modern installers have the necessary functionality to manipulate the contents of the INI text file, or you can write your own post- install executable to update the contents.

Windows Registry entries are the last configuration mechanism we are going to discuss. The main difference with the Windows Registry is the settings are specific to the machine. The other two storage schemes can reside in a centrally located place and be shared across a network if desired. The Registry is part of the operating system and locked to the machine. You can store entries for different users or you can share them for all users on the same machine. Installer tools can create and update keys in the Registry, which simplifies deployment. The applications need to understand the hive and location of the keys to get the values. This is not a surprise and is not a limitation, just a fact you have to synchronize the application and the installer to deploy the correct entries in the Registry.

Runtimes

We discussed the runtime file installation issues in Chapter 1, ‚“Deployment Fundamentals, ‚½ and in greater detail in Chapter 3, ‚“Packaging the Installation, ‚½ in the ‚“Visual FoxPro runtimes and dependencies ‚½ section. The issue with single workstation deployments is the runtimes are only on the one machine. In a local area network the runtimes can be deployed on the workstation or on the file server.

We recommend always loading the runtime files on the workstation if possible for performance reasons and loading them in the recommended folders per the Microsoft recommendations. If you use the provided merge modules they are loaded in C:\PROGRAMFILES\COMMON FILES\MICROSOFT SHARED\VFP\ folder. Installing them on the workstation saves the network traffic and loads your applications faster.

Shortcuts

Shortcuts are important for the end users to execute applications, access support tools, open a Help file outside of the application, and read documentation files or any other file useful in day-to-day use of the solutions you deploy. You have two types of shortcuts in your deployment packages, required and optional.

Required shortcuts are shortcuts you want installed every time one of the installation types is selected. If you are installing the application, you want to include a shortcut to the application. If you are installing the Help file for the application, you want to include a shortcut to the Help file. These shortcuts are included on the Windows Start menu under Programs if you follow industry standards, but you have plenty of options:

• On the Start menu

• On the All Programs menu

• In a folder underneath the All Programs menu

• In a subfolder underneath a folder underneath the All Programs menu

• On the user ‚ s Desktop

• In the user ‚ s Startup folder

• In any predefined Windows folder

• In any custom folder you want to create

At a minimum we recommend a shortcut to the application executable if the user is going initiate the application. The shortcut should be located under the All Programs level and possibly a folder under this folder. This is going to depend on your customers and their needs, but we set up a company folder and create our application shortcuts under this folder. If we have more than one application, we create subfolders under our company folder for the applications and create the necessary shortcuts under this folder.

Note ‚  

We know this is an obvious note, but no matter where the installation package creates shortcuts, your users can move them and copy them to other places on their desktop like the Quick Launch toolbar, the Startup folder, and even move them around on the Start menu. Creating one shortcut is all they need to save them the time of creating one in another location as they can copy your original. The reason we note this is you can find yourself spending more time than it is worth figuring out how to create icons all over the target machine. Simplifying the install might be the best thing you can do in this regard.

Optional shortcuts are shortcuts users can selectively install (see Figure 5 ). Not all installer tools support this functionality. These optional shortcuts provide the user with additional control and options during the installation. For example, we do not appreciate software packages installing desktop icons. It is our opinion the desktop is a personal space customized by every user. How can the creators of the software we purchase determine automatically that we want an icon on our desktop for their application? We actually find it intrusive . We also know some users are absolutely going to want a shortcut on their desktop for some applications, especially if they use them all the time. That is why they are called shortcuts. Knowing there are two sides to this situation and both sides feel passionate about including or not including the shortcut, we feel it is better left as optional. Shortcuts on the Quick Launch toolbar might be a candidate for optional shortcuts as well.

Figure 5. The Inno setup process allows users to determine if they want a desktop icon included as part of the installation.

ActiveX controls and COM objects

The current version of Visual FoxPro is much better at interacting with newer ActiveX controls than earlier versions. Today developers can save time by using functionality that already exists in an ActiveX control developed by a third-party vendor (see Figure 6 ). ActiveX control files (OCX) must be installed and registered on the workstation (see Table 3 ).

Figure 6. The Scheduler control from DBi Technologies provides a simple interface that would be difficult to create in a short time with native Visual FoxPro controls. It is also easy to deploy with your installations.

Table 3. ActiveX controls (OCX) can be registered and unregistered manually at the command line.

Operating System	Process	Command Line
Win9x	Register	[WINDOWSFOLDER]\SYSTEM\REGSVR32 [PATH]\MYACTIVEX.OCX
‚	Unregister	[WINDOWSFOLDER]\SYSTEM\REGSVR32 /U [PATH]\MYACTIVEX.OCX
WinNT/2000/XP	Register	[WINDOWSFOLDER]\SYSTEM32\REGSVR32 [PATH]\MYACTIVEX.OCX
‚	Unregister	[WINDOWSFOLDER]\SYSTEM32\REGSVR32 /U [PATH]\MYACTIVEX.OCX

It is not uncommon for developers to integrate e-mail processing in their applications via a MAPI control or an SMTP control. Compressing and uncompressing files is simplified using the DynaZip controls from InnerMedia. Vendors like DBi Technologies have plenty of Visual FoxPro sample code shipping with their products so you can get up to speed with the functionality quickly. If an ActiveX control is not loaded properly your error handling code gets tested immediately.

Most third-party ActiveX providers give detailed help about installing the OCX files and registering them on the workstation. It is important to know which OCX files are required, where to install them on the developer ‚ s machine, where to install them on the customer ‚ s machine, and which files not to install such as the developer license files that ship with some products. Also, pay attention to the distribution licensing for an ActiveX control. Most provide unlimited, royalty-free licensing. If not, make sure your deployment complies with the licensing.

COM Objects can be installed on the local workstation or accessed via Distributed Component Object Model (DCOM). It is outside of the scope of this chapter to discuss DCOM, but we are compelled to list it here as an option. Modern installers automatically register these components. If you are using an alternative method like XCOPY or an installer not supporting the registration process, you can use the Windows RegSvr32 utility on the workstation (see Table 4 ).

Table 4. ActiveX COM objects can be registered and unregistered manually at the command line.

Operating System	Process	Command Line
Win9x	Register	[WINDOWSFOLDER]\SYSTEM\REGSVR32 [PATH]\MYCOM.DLL
‚	Unregister	[WINDOWSFOLDER]\SYSTEM\REGSVR32 /U [PATH]\MYCOM.DLL
WinNT/2000/XP	Register	[WINDOWSFOLDER]\SYSTEM32\REGSVR32 [PATH]\MYCOM.DLL
‚	Unregister	[WINDOWSFOLDER]\SYSTEM32\REGSVR32 /U [PATH]\MYCOM.DLL

You can run the following commands at the Windows command line to register and unregister an EXE COM component:

 [Path]\MyExe.EXE /RegServer  [Path]\MyExe.EXE /UnRegServer  

Automation

Applications that rely on Automation Servers need to verify they are loaded or handle the errors when they fail. Installer tools look for some products like Internet Explorer, but that is the extent of checks they make.

In Chapter 2, ‚“Planning for Success, ‚½ we presented several code samples to check for automation applications like Word, Excel, PowerPoint, Outlook, Access, FrontPage, Project, Visio, MapPoint, and Acrobat in the section titled ‚“Integration with other applications and technologies. ‚½ These checks have to be part of your application or a post-installation executable if you want to inform your users at the time of the install.

ODBC DSN

We discuss the ODBC connectivity at length in Chapter 7, ‚“Client/Server Application Step- by-Step, ‚½ for a SQL server based datasource. In the context of Visual FoxPro data, your clients might access their database via Microsoft Excel for graphing, or Microsoft Access for reporting, or more sophisticated and user friendly ad hoc reporting tools like Crystal Reports, Stonefield Query, FoxFire!, and Business Objects.

Your customer ‚ s requirements dictate the type of components you install. If your customers are using tools that require ODBC connectivity, you need to install the Visual FoxPro ODBC driver. If the tools are OLE DB aware, you can install the Visual FoxPro OLE DB provider. We recommend installing both of them because the ODBC driver and OLE DB provider can co-exist on the target computer (see Figure 7 ). In addition to the drivers you might want to set up a datasource name (DSN) (see Figure 8 ). The DSN can be set up manually by the end users, programmatically using Windows Scripting Host object model, programmatically manipulating the Windows Registry, or using one of the many commercial deployment tools.

Figure 7. You want to include both VFP data merge modules (VFPODBC.MSM and VFPOLEDB.MSM). This example shows the Wise for Windows Installer selection dialog.

Figure 8. Setting up an ODBC DSN using a Windows Installer deployment tool is as easy as checking one of the existing DSNs from the source machine and setting properties.

FoxTools and other FLLs

Each version of Visual FoxPro seems to include more and more functionality formerly included in the FOXTOOLS.FLL library. We rarely deploy this file any more, but numerous functions are included in the file that you might deploy. Years ago we came to the conclusion that installing the FLL file along side the runtime files allows us to simplify the code to locate the library and release it.

  IF "FOXTOOLS" $ UPPER(SET("LIBRARY"))   * Nothing to do  ELSE     SET LIBRARY TO HOME()+"FoxTools.fll" ADDITIVE  ENDIF  

To release the library you can use this code:

  RELEASE LIBRARY HOME()+"FoxTools.fll"  

Another approach is to release it in the same folder as the application executable so it can be found in the current default directory. Both approaches require two copies of the library file because we test out the executable on our development machine without the Visual FoxPro development environment. The code looks for the library in the runtime folder or the executable folder.

One other aspect of deployment you need to be concerned with is versioning. Each version of Visual FoxPro comes with a new version of FOXTOOLS.FLL. Make sure to deploy the correct version with the deployment package.

Help files

Help files can be loaded on the local workstation or the server. We prefer to load Help files in the same location as the executable for one simple reason: the application can easily find the Help file without the need for additional configuration files or registry entries. If you use a configuration, make sure the installation is smart enough to update this configuration to reflect the location of the Help file so the application can locate it when the user presses the F1 key.

In addition to the HTML Help file, you also need to include the Visual FoxPro HTML Help runtime files in your deployment package. We discuss which files and the corresponding merge modules for the additional VFP runtime files necessary for running HTML help in Chapter 3, ‚“Packaging the Installation, ‚½ in the ‚“Visual FoxPro runtimes and dependencies ‚½ section.