Organizing the setup

Before you can build the installation setup you need to know where the various files are going to be installed in the customer ‚ s environment. First you need to determine the files as we previously discussed, now you need to determine the directories where the files will reside and on which machine those directories will be placed. After you resolve the directory issues, you need to determine the installation schemes and how to deploy the feature sets so the users can implement the system efficiently .

Directories

The Setup Wizard that shipped with Visual FoxPro 3/5/6 required you define the directory structure and include the files in the directories for the Wizard to include in the Acme Setup exactly as you wanted them on your customer ‚ s machine. This forced developers to plan the installation directories before they created the installation routine, but required a second copy of all the files, and as new ones were generated, developers had to remember to copy the new files to this Setup Wizard structure. The new installer tools do not require the separate directory structure to indicate which files are distributed, but you do need to understand where the files reside in the production environment.

Each developer is likely to have their own ideas on how their customer ‚ s environment should look. There are corporate standards, developer recommendations, and industry standards to consider too. We offer some items and ideas for consideration in this section.

We dedicated a complete chapter (Chapter 5) to the Windows Installer technology as well as four separate appendices on how to work with and use some of the installer tools. Each of these tools has techniques to create directories and copy the files to these directories. You will see in the chapters a number of operating system and installer-recognized folders exist to assist you in picking standard directories and allowing the flexibility to create your own.

Executables

Executables are installed on servers (multi-user), on workstations (single-user and multi-user), on local area networks, wide area networks, in distributed mode, and on Web servers. The current standard is to default the install of the executables in a folder under the Program Files folder. The ultimate control should be placed in the user ‚ s capable hands. We find it quite irritating when a package installs itself where it deems fit, not where we want it. In fact, we consider deleting and not using a package not friendly in this regard. We hold ourselves to this standard as well. We also understand some corporate environments do not want the users to control things of this nature and we respect those deployments by removing this flexibility.

Some packages install the application in a folder directly below the Program Files folder and some companies create a company folder below the Program Files folder, and then install all the applications from their company in a folder under the company folder. This is the approach we like, but it is not required. In fact, there is nothing saying you cannot install your application directly off the root folder. We just feel it gives the application a more professional look when it follows industry standards.

Help and documentation files

The Help files are typically installed in the same folder as the executable to simplify locating the Help when the F1 key is pressed or the Help menu option is selected. Documentation can come in many forms such as word processing document files, Adobe Acrobat files (PDF), or additional help files. We typically install the documentation files in a folder called DOCUMENTATION under the directory where the executables are loaded. There is no industry standard to reference for these files.

In the case of HTML Help, you need to be aware there is a runtime Help subsystem that needs to be installed to access Help from a Visual FoxPro based application. The subsystem is easily installed if you use the VFP8HTMLHELP.MSM merge module. If you do not install the Help runtimes via the merge module you need to install the FOXHHELP8.EXE and

FOXHHELPPS8.DLL files (for Visual FoxPro 8) or FOXHHELP7.EXE and FOXHHELPPS7.DLL

files (for Visual FoxPro 7).

FLLs

The only FoxPro Linked Library (FLL) files we are currently distributing with our applications are FoxTools (that comes with VFP) and, when necessary, the Amyuni PDF- generating FLL. Our experience has lead us to install the FLL files in the same directory as the runtime files. The only reason for this is to be able to find the file easily with the HOME() function. When we want to set up the library we have code similar to this:

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

When we want to release the library we have code that looks like this:

 RELEASE LIBRARY HOME()+"FoxTools.fll" 

This does require two copies of each FLL to reside on the development machine because sometime we run the application inside Visual FoxPro (which looks in the VFP folder for the FLLs), and other times we test the EXE standalone (which looks in the folder with the runtimes). We find this extra copy on the development machine to be a non-issue because it simplifies testing and implementation in the customer environment.

Shortcuts

Shortcut files are a nice way to give your clients access to the applications you develop. A shortcut file is nothing more than a system level file that opens the file it is a shortcut for. The most common place shortcuts are created is on the Start Menu, but they can be created on the Windows desktop, on the Windows taskbar in the Quick Launch toolbar, or in the Start Up folder. You can also create subfolders under these folders and add shortcuts to these new subfolders .

What you create shortcuts to is going to depend on your client ‚ s needs. Things to consider are the application executables, the Help file, custom Adobe Acrobat files (containing documentation, special instructions, last minute announcements, or updates), a bug reporting application, and any utilities you might have for the application. Consider anything that is important for the customer to have quick access.

Runtimes

The runtime location was discussed earlier in the runtime section under ‚“Getting Ready for Delivery. ‚½ We recommend you follow the standards deployed by using the merge modules, but as stated in this section, different circumstances will dictate the course of action you need to take for your own installations.

Data

Selecting the data directory folder should be similar to selecting the application folder, and under the control of the user/customer. At least this is the case for Visual FoxPro data. The location might also be dictated by the architecture of the application.

SQL backends have processes of creating and restoring data that dictate and/or allow data folders to be selected. Again, corporate standards or a database administrator might dictate where the data goes, which is all the more reason to make this part of the installation as flexible as possible.

Third party ActiveX and COM

We recommend checking the documentation provided by the vendors of all third party ActiveX controls and COM objects. The documentation should have a deployment section that tells you if there are any deployment requirements or recommendations. Also check to see of the vendor provides a Windows Installer Merge Module to include in your installation. The nice thing about merge modules is they already contain the necessary registration information for the control.

Images, icons, video, and sound

The rest of the ‚“external ‚½ files are files integrated into the application at runtime instead of compile time. These files may be generic or custom to a specific deployment. For instance, you might include the company logo as an image on the splash screen, about window, and on reports . Each customer naturally has their own custom logo so you might include a LOGO.JPG

in an image folder that each company can replace with their own custom file (or might be one you include in the setup). Icon, sound, and video files might be included or excluded depending on size , and the need for customization at a particular location.

Installation schemes/feature sets

After the directories are created and the correct files are placed in them, you need to determine what installation scheme you need for the release. We are sure there are numerous schemes to create an installation process. The following ideas are ones we found successful for our Visual FoxPro application deployments. We may combine several installs into one package or we might ship separate installs based on the customer ‚ s environment or needs. We separated the upcoming discussion based on the different options you can include in an installation package.

File server install

This is the main application installation and is included in nearly every installation package delivered to the customers. It includes all the core application executable files needed to run the application. This is the ‚“base ‚½ installation and includes all the files found in the installation root, system, sound, images, and any other directories needed by the application.

This install is typically used in a network environment. The installation loads the core application files on the file server in a specified directory. Once the files are loaded, the users have access to the application provided they have network access and rights to these files. Using this scheme also requires all the workstations have the Workstation Install (discussed next ) loaded so they have the Visual FoxPro runtimes.

This installation also works on a client PC for a single user application provided the files from the Workstation Install and the Data Install are also installed. Many developers who have single PC clients use this technique all the time.

Workstation install

If the application is loaded on the file server, is it ready to be executed by the connected workstations with security access? Not necessarily . Each workstation needs additional files loaded. These include the Visual FoxPro runtimes, any ActiveX controls, and the Help system engine. You could go around to each workstation and reload the File Server Install (discussed in the previous section), but this can be time consuming and unnecessary. The idea of the Workstation Install scheme is to load only the files needed. We broke the Workstation Install into five components , each can be included on one installation CD-ROM. You may find there is more or less than this depending on your needs.

• Visual FoxPro runtimes: we find application startup performance is best when the Visual FoxPro runtimes are loaded on each client workstation. Do the runtimes really have to be on the client workstation? No, see the ‚ D directive to the VFP8.EXE (and consequently, your custom executable), but it is faster because you are not pulling 4MB down the pipe every time you start the app. This install loads all the Visual FoxPro runtimes including VFP8R.DLL and VFP8RXXX.DLL (where the xxx is the language of the Visual FoxPro version you have, e.g., ENU for English).

• Multi-threaded Runtimes: this loads the VFP8T.DLL file for multi-threaded COM objects. Not all applications require the multi-threaded functionality, so installing this for your customers may not be required.

• HTML Help Engine runtimes: these files are only needed if you include a CHM file with your application. If you decide to build WinHelp files (HLP) or a table based Help file, you do not need this installation.

• Visual FoxPro ODBC driver (VFPODBC.DLL and VFPODBC.TXT file) or OLE DB driver (VFPOLEDB.DLL) and others if needed: this gives your users a way to analyze their data via tools like a spreadsheet, perform mail merges from a word processor, or build their own queries via an end user database or tool.

• ActiveX controls: the key to this install is to make sure the ActiveX controls included in the application are installed on the workstation. These files are loaded into the appropriate directory and installed in the Windows ‚ Registry. You need the ActiveX controls loaded on the computer where the installation is built. It is important to note the ActiveX controls loaded during an install can be the ones included with Visual FoxPro and Visual Studio as well as any third-party controls purchased.

Any of these components can be included or excluded from the install based on the requirements of the application and the deployment. You may decide to customize for a specific customer. It may be that you build one app with various ActiveX controls and another app for a different customer without ActiveX controls, or a different app with different controls. This installation can be passed around from computer to computer or run from a directory on the server (just installed on the workstation). We also recommend the CD is dated and note the Visual FoxPro version and Visual FoxPro service pack that the runtimes apply. It can be embarrassing to have that new Session class in Visual FoxPro 6 Service Pack 3 not be available with a new executable running on prior versions of the runtimes.

Data install

Obviously this installation section is for the application data. The questions that need to be asked may complicate this seemingly easy setup, though. What files need to be sent? Is this Visual FoxPro local data or are you using a SQL backend database? What tables need to be pre- populated ? What files can be generated at the customer site? What about installations that already have previous installations with data loaded?

Initial installations require all the application data be installed and found in the installation data directory. We like to keep this installation separate, especially for a new service pack release. Vertical market applications like this scheme as well because it allows a development shop to build a single installation package for new customers and existing customers getting a new version.

Web Server Install

A Web Server Install may mirror a File Server Install scheme in many ways. However, you may encounter many differences with your application. Most likely you will install the Multi- threaded runtimes for scalability, COM components or an EXE, HTML files, and will make Web Server settings (via executable or manual settings) like scripting files, user security, and the mapping of drives to the data.

How do you package the install?

Now that you have developed schemes for the installation, you need to determine how to package it. We are not referring to the box the CD is delivered in. The marketing expert can best handle this. We are suggesting you need to think about what install schemes discussed in the earlier section need to be packaged and sent to the customer.

Typical brand-new installs for a LAN based application require the File Server, Workstation, and Data Install schemes. Updates may only require the File Server Install. On the other hand, if the executable is built with a new version of Visual FoxPro you may need to ship at least part of the Workstation Install to include new runtimes. A Web Server may only need some new HTML files so you can skip the need to update COM objects. Single computer customers may require the File Server Install and the Workstation Install be combined into one installation process.

The packaging of the install is as important as developing perfect software because it is generally the first impression most users have of the application in production. We are not talking about the people you developed the software specs and performed acceptance testing with; we are talking about the possible hundreds of end users that actually get the package loaded on their computers.

OS and third party components

Today ‚ s software can easily be based on components. While we like to think Visual FoxPro is a comprehensive development tool, it is not uncommon to find our applications interacting with a specific operating system and third party components. The component environment is powerful and can provide features that would take us a long time to develop. This saves developers ‚ time and clients ‚ money. The flip side of the equation is you need to ensure the components are installed. This means an extra burden to find out the licensing issues for deploying the component, how it can be done, and what mechanisms are available that can be leveraged.

While we hope our customers have the latest and greatest operating system, and they have all the components available, this is typically not the case. You definitely cannot rely on the environment being established exactly as our applications need it. It is not unusual to interact with the Windows Script Host (WSH), Microsoft Data Access Components (MDAC), and the Microsoft SQL Server Desktop Engine (MSDE). All of these components can ship with our installation setups, or be downloaded from the Microsoft Web site by our customers. How they get there depends on how you want your application perceived, how sophisticated your customers are (they may have an internal computer department that will update the machines), and how well you can integrate the component in your setup.

The same concepts need consideration when dealing with ActiveX controls and third- party COM objects. You may find the vendor already has a package you can use for your deployment, or you might have to consider creating the necessary registration process. Most of the current installer packages read the ActiveX control or COM object and make the necessary registrations for you during the installation. If you are not using an installer to do this or are doing things manually, you need to figure out what has to be done so the application and the operating system are set properly to work together.

You will find the optional operating system components from Microsoft, ActiveX controls included with Visual FoxPro and Visual Studio, as well as many third-party products have merge modules to use with installers that leverage the Windows Installer. More information on merge modules and the Windows Installer is found in Chapter 5. The install package vendors usually have many merge modules for components available for downloading on their Web site.

Utilities to consider shipping

While the main goal of the developer is to install the files needed for the customer ‚ s application, there are a number of developer utilities that can assist in the installation and ongoing maintenance that is likely to occur. The following are concepts for the tools we developed, downloaded from the Internet, or purchased for the types of applications we deliver to our customers.

Reindex and database updater

Initial releases usually start with an empty database or have a data converter preload the database. What happens when an upgrade is released and the latest alterations to the database tables, indexes, views, and relations need to be implemented? You could write a custom program each time to make these changes via the powerful ALTER TABLE and INDEX ON commands. You can also keep track of each change made to the data and make sure this custom program is updated every time a change is made in development. Even for single developer projects this can be a tough task, and the odds of missing one critical change are nearly even. Multi-developer projects get to be more than a challenge in this respect; they become a communication nightmare.

Keeping track of these changes can be automated. We do not want this to become a commercial for the Stonefield Database Toolkit (SDT), but we find so much value in this product we have to give it a plug. It keeps track of your changes to the data structures in the DataBase Container eXtensions (DBCX) and SDT metadata. SDT provides a NeedUpdate method to check for differences in the metadata and the structures in the database. If there are differences you can run the SDT Update method and the structural changes are applied to the database tables. This means columns are added or removed, column name changes are applied, and code pages can be changed. The same is true for indexes. It also creates new tables if they do not exist. This is all handled based on using the DBCX extensions to the database via the Stonefield Database Toolkit or a tool you developed yourself (yes, you can develop one since DBCX is a published standard). The key to this is to validate the database extensions before you ship out the metadata with the release (a lesson learned on this author ‚ s very first release with this product). SDT can be used in initial installations to completely generate all the tables as well.

There is another option to solve the database changes and that is to simply make the changes manually. If you develop on-site with the application, you can just use VFP live on the data and make the changes. We hear of this all the time. However, we are just not the kind of developers that trust ourselves to remember to make the changes in the same fashion we did in development. We are sure there are plenty of war stories to be told that would convince you not to do this. On the other hand, emergency fixes that can be done to keep a customer alive are made all the time.

One thing SDT does not handle that you need to consider for all types of releases is data conversion. Even if you have an automated way of updating database structures and the like, you need to consider a mechanism of populating new fields, converting data from old tables, and cleaning up data that might violate new field or row level rules. You might even need a separate program that cleans up the data before implementing a new field or row level rule for a table.

SQL databases require a different approach because there is no tool like Stonefield Database Toolkit for SQL backend databases. You need to generate scripts to execute on the backend database. These scripts can be generated or programmed. The scripts can then be run manually or programmatically on the backend database. We know developers that create script logs in a DBF and programmatically execute the scripts in a certain sequence to bring databases up to date for a specific version of the application. We recommend checking Chapter 10, ‚“Application Distribution and Managing Updates ‚½ in Hentzenwerke Publishing ‚ s Client-Server Applications with Visual FoxPro 6.0 and SQL Server 7.0 for plenty of ideas and suggestions on approaches for deployment mechanisms and tools for new and updated database schemas.

GenDBC/GenDBCX

If you are not using SDT and/or want a mechanism to generate a Visual FoxPro database and all the table structures, views, indexes, and relations, take a look at GENDBC.PRG (included with each release of VFP) or GENDBCX.PRG. GenDBCx is a third party tool written by Steve Arnott, which is available for free. You can download it from http://www.leafe.com/dls/vfp . Both of these tools generate Visual FoxPro program code that builds the database from scratch. Just like the SDT Update process, neither of these tools populates the tables so you need a mechanism to accomplish this task.

Note ‚  

If you run the code generated by GenDBC or GenDBCx on a production directory that already has the files populated with customer entered data, the data will be lost because the programs create new structures without data.

Checking next ID table

Developers who use surrogate keys (meaningless integers or characters that uniquely identify a record in a table) often have a table that contains the next key for tables (Visual FoxPro 8 has the new AutoIncrement field type to also use for this purpose). Periodically these tables get misaligned with the real data in the tables. This can happen because the developer writes bugs in their applications; tables get zapped moving from development to production without updating the next surrogate key table, incorrect referential integrity rules, or the planets being out of alignment.

For whatever reason, the next ID table needs to be synchronized with the data in the tables. This process needs exclusive use of the database and each table. The general algorithm is to get the maximum key value from the table via code like:

 SELECT MAX(nTablePK) ;  FROM Customer ;   INTO ARRAY laMaxID  

Once you have the maximum ID for the surrogate key, the next ID table record for the table is updated with this new value if necessary. It is a good idea to run this process for all the tables in the application periodically. One red flag that indicates it might be time to give this process a run is the constant calls from a customer that they cannot add any records into any form because they are getting a message indicating duplicate keys values.

If you are using Globally Unique Identifiers (GUIDs) you do not need a tool like this. GUID keys are not incremented; they are generated on the fly by making calls to the operating system.

Configuration/Control table updater

Many applications have an INI file or a configuration table. When new options are added a mechanism to incorporate these options into an existing application needs consideration. Personally we prefer to work with tables since we work with these all day and Visual FoxPro provides plenty of commands to manipulate data. Adding new options is as simple as an APPEND FROM or running code to do an INSERT INTO . Updates are as simple as a LOCATE or SEEK and using REPLACE s, or writing code that does a SQL Update. The INI text files are also easy to work with because Visual FoxPro has low-level file input and output commands to manipulate text files. There are also Windows ‚ API calls to INI files available for developers with this knowledge.

The important item to note is you develop some mechanism to update this information so the customer application does not malfunction when new options or features are added.

Runtime command window

FoxBox is a utility developed by Alex Korot of West Bloomfield, Michigan. It is not something you will use everyday interactively within the Visual FoxPro development environment, but it could be a tool you find indispensable for your customers when you are on-site or doing some remote support via pcAnywhere or a Remote Desktop Connection. FoxBox, shown in Figure 5 , is a Command Window (and much more) without having a full copy of Visual FoxPro loaded on the customer site. It does require the same runtimes installed for your application.

Figure 5. FoxBox is indispensable when debugging support issues on a customer ‚ s computer that does not have Visual FoxPro installed.

On The Web ‚  

FoxBox can be downloaded from www.KirtlandSys.com or www.RickSchummer.com

This tool allows you to run any command in Visual FoxPro that does not fire the ‚“Feature not available ‚½ error. Therefore, you can open a table and browse it, you can perform SQLSelects to inspect data, you can fire up a REPORT FORM , recreate an index, or you can open text files. All the things you want to perform with Visual FoxPro, but do not want to build into your executable, can be accomplished via FoxBox.

The cursor browser (via browse button on FoxBox Console) displays a smarter browser. You can sort the cursor based on available indexes and by clicking on the column headers. The Structure button displays much more than the LIST STRUCTURE command produces.