Generating a setup, step-by-step

Step 1 ‚ Organizing your setup

There are several suggested changes to make in the setup organization step.

The first change is to eliminate the setting for the DATABASEDIR property. For traditional applications, set the property to a folder for the data. Client/server data is going to be installed on a database server, not to a folder. However, this property could be used to store the location of the SQL script files. Using this property allows the database administrator to determine where the scripts install separate from the rest of the application files. In the example setup (DEPLOYFOXSAMPLE7.ISM) available in the chapter downloads, we set the DATABASEDIR to [INSTALLDIR]SQLScripts. This is the administrator ‚ s default directory, which they can override as long as the Database Folder dialog is included in the setup.

We add two more features to our client/server setups. The first is MDAC. We use this feature to include the Microsoft Data Access Component merge modules or the standard setup EXE from Microsoft. The other feature is MSDE, used to include the necessary files to install the Microsoft SQL Server Desktop Engine for those customer sites not running the full version of SQL Server. If your favorite database has setup files you can include as part of the setup, we recommend including them. You can also create a separate install for these files as well.

We use the same model included in chapter six for the Setup Types (Workstation, Server, and Custom). What we have to do is determine where we want to add the two new features. This is actually a tough call. What we settled on based on our experience is including both features only for the Custom setup. The reason for this is the average user who might run the install probably is not going to setup a MSDE database server. The same philosophy applies to the MDAC files. Most users are not going to determine they need the MDAC files and there is a good chance they already have them installed from another product purchased from Microsoft, through the Windows Update, or via a Windows service pack. Including them in the Custom install gives sophisticated users, developers installing their own applications, or trained technical support personnel the ability to install the components.

Step 2 ‚ Specifying files deployed

The files you deploy from a Visual FoxPro perspective do not change. You still need your executables (EXE/APP/DLL) and your runtime files. If you still need to deploy optional files like DBCX and framework metadata, INI, Config.fpw, ActiveX controls, and a Help file. You need any remote view database containers if your applications use remote views. So what are the new files you need to include?

If you are using SQL Server or MSDE, you potentially need to install the Microsoft Data Access Components (MDAC). The straight scoop from the Microsoft Web site ^[2] :

‚“Microsoft Data Access Components (MDAC) is a set of software components used to provide applications a means to access data from various data storage sources, with a focus on access to Microsoft SQL Server. A large number of applications depend on MDAC-contained components for proper operation. MDAC is not a single product; rather, it is a collection of DLLs and associated component resources to support a number of different APIs, including Open Database Connectivity (ODBC), OLE DB, Microsoft ‚ ActiveX ‚ Data Objects (ADO), and Microsoft Remote Data Service (RDS). MDAC installation not only places a large number of common shared files in various places across the Microsoft Windows ‚ system drive, MDAC is also responsible for adding many registry keys to the registry. ‚½

You can take two approaches to this. If you are not using a Windows Installer deployment package, you can download the MDAC components from the Microsoft download center. The easiest way is to search for ‚“MDAC Download ‚½ on Microsoft.com and select the components needed for your application. The download is an executable that runs a setup and installs the components (see Figure 17 ). You (or the person making the install) need to manually run this after the MDAC install file is installed through your deployment package. The second method is to use one of the merge modules available (see Figure 16 ). Table 3 helps you determine which version of MDAC you might want to install. We recommend checking out the vast number of articles posted on the Microsoft knowledgebase to help you make the best choice.

Figure 16. One way to install the MDAC components is to select the available merge modules, and then select the features you want it installed for.

Figure 17. Another way to install the MDAC components is to install the raw installation setup executables and have a user or support individual manually run the install.

Another file you might want to include is the MSDE installation. Like the MDAC components, there is a merge module for Windows Installer deployment tools and a standard install executable for developers using other tools or want a more manual installation. We prefer to install MSDE ourselves in the situations where the customer does not already have a database server installed, or a database administrator on staff or contracted for the project. The MSDE installation file can be downloaded from the Microsoft Web site, and is included with numerous developer tools and the MSDN Universal product. We found the merge module at http://support.installshield.com .

If your application is automating SQL Server or you are using custom tools to automate SQL Server, then you need to install the SQL-DMO files (see Figure 18 ). These files need to be loaded in the Windows System Folder or in the application folder. More information on SQL-DMO and a reference to a great book can be found in the section ‚“Using SQL-DMO, ‚½ earlier in this chapter.

Figure 18. You need to install the SQL-DMO files if your application performs any ActiveX automation control over SQL Server. The figure displays the Files and Features view inside InstallShield Express.

Step 3 ‚ Configuring the target computer

Your client/server application has similar setup details with respect to shortcuts, registry entries, INI file changes, file extensions, and environment variables . Setting up your ODBC Data Source Names (DSN) is important if the application architecture expects to use one or more DSNs.

Configuring the DSN within InstallShield Express or another deployment tool is not difficult. How complicated it is depends on your target computers. If you know the server and the database name on the target computers the configuration is very straightforward. If you do not know, the user or technical support individual has to make some changes to the DSN via the ODBC Data Source Administrator after the install completes. If you are a vertical market application developer, you might want to take a different approach because you probably do not want to rely on customers anywhere in the world making changes to the DSN. You may find it better not to use a DSN or have a programmatic setup of the DSN in your application when it starts for the first time.

Once you select the DSN in the ODBC Resource pane (see Figure 19 ), you have the opportunity to select and change properties for the target computer DSN. The properties can differ depending on the datasource. If you are using SQL Server these include the Description, Registration, Driver Description, Database, Server, and whether you are connecting through a trusted connection.

Figure 19. Adding a DSN to the deployment is easy if you have a DSN to model the DSN you want created on the target computer. First, select the existing DSN in the ODBC Resource pane, determine which feature you want the DSN installed, and then configure the Database and Server properties in the Properties pane if they differ from your system configuration.

The rest of the story

Steps four, five, and six are really not any different between client/server and traditional workstation/LAN application. You still need to determine which dialogs make sense, whether you are going to use and possibly change Billboards, and change text messages if necessary. The requirements selection could be important, but again, no different from the traditional applications.

Building your release could be slightly different in one aspect, namely the size of the deployment package. If we compare exact applications, both with empty databases deployed by running a script, it is very likely your client/server deployments have more files like MDAC merge modules (or setups), MSDE merge modules (or setups), the SQL-DMO files, and the script files. The additional files are not a stumbling block, but for those developers shipping products over the Internet, or have clients who download from their Web site, the transfers could take significantly longer. We distributed a 120MB install over the Web via FTP. Even with high-speed lines this transfer took more than an hour . If your client is waiting on a critical bug fix this could be a problem.

Each deployment is different and each client has a different set of circumstances, therefore you may require different files to be deployed, different combinations, different features, and different tools. Each of these impacts the final deployment package.