Alternatives to InstallShield Express



Alternatives to InstallShield Express

Jim Williams

In the January issue of FoxTalk, editor Whil Hentzen asked, "Where is the Setup Wizard?" This month, Jim Williams replies, "Right where it always was: in VFP 6." He explains how to use it for VFP 7 applications, for those of you who don't have time right now to install and learn InstallShield Express. But for those who are ready to take the plunge, he explains how you can use InstallShield to provide your clients with the option of installing (and uninstalling) only part of your application, while providing some tips to keep you out of trouble. Finally, in the spirit of FoxPro's tradition of providing more than one way do something, he explains how to do deploy VFP 7 applications with Wise Solutions products.

There's always comfort in the familiar. For many developers, the installation process for Visual FoxPro 6, relying on the Setup Wizard, worked just fine. Why try out new and untested tools when the old ways worked fine? Wouldn't it be nice to use the 6.0 Setup Wizard with your 7.0 applications?

The VFP 6.0 Setup Wizard

What if you test your install package and it blows up? What if you don't have time to install InstallShield Express, let alone learn how to use it? Isn't there a way to use the old, familiar Setup Wizard? Yes, there is. First, create and populate a distribution folder as usual. Then copy the appropriate runtime files to the newly created distribution folder (see Table 1). Start the wizard and make the same choices that you would for a VFP 6 application, except in step 2 of the wizard, don't specify Visual FoxPro runtime, and in step 6, change the target directory of the runtime files to WinSysDir.

Table 1. FoxPro 7 runtime files.

|All applications |File |

|[Windows System] |MSVCR70.DLL |

|[Windows System] |MSVCP70.DLL |

|[Windows System] |MSVCI70.DLL |

|[Program Files]\Common Files\Microsoft\Shared\VFP |VFP7RENU.DLL |

|[Program Files]\Common Files\Microsoft\Shared\VFP |VFP7R.DLL |

|Language Other than English |

|[Program Files]\Common Files\Microsoft\Shared\VFP |VFP7Rxxx.DLL |

|Server Applications (see FoxPro Help for more information) |

|[Program Files]\Common Files\Microsoft\Shared\VFP |VFP7T.DLL |

|Active Documents |

|[Program Files]\Common Files\Microsoft\Shared\VFP |VFP7RUN.EXE |

|OLEDB for VFP |

|[Program Files]\Common Files\System\Ole DB |VFPOLEDB.DLL |

|ODBC for VFP |

|[Windows System] |T |

|[Windows System] |DRVVFP.HLP |

|[Windows System] |VFPODBC.DLL |

|[Windows System] |DRVVFPC.TXT |

|[Windows] |DRVVFP.CHM |

|XML |

|[Windows System] |MSXML3.DLL |

|[Windows System] |MSXML3R.DLL |

|HTML Help |

|[Windows System] |FOXHHELPS7.DLL |

|[Windows System] |FOXHHELP7.EXE |

|Web Services and SOAP |

|[Program Files]\Common Files\MSSoap\Binaries |*.* |

|[Windows System] |MSVBVM60.DLL |

|[Windows System] |COMCAT.DLL |

|[Windows System] |ASYCFILT.DLL |

|[Windows System] |OLEAUT32.DLL |

|[Windows System] |OLEPRO32.DLL |

|[Windows System] |STDOLE2.TLB |

|Common ActiveX controls |

|[Windows System] |MSVBVM60.DLL |

|[Windows System] |COMCTL32.OCX |

|[Windows System] |MSCOMCTL.OCX |

|[Windows System] |MFC42.DLL |

|[Windows System] |TLBINF32.DLL |

|[Windows System] |TABCTL32.OCX |

|[Windows System] |SYSINFO.OCX |

|[Windows System] |RICHTXT32.OCX |

|[Windows System] |PICCLP32.OCX |

While this is a quick way to get your application out the door, it's not foolproof. Be sure to test it to make sure you don't have any controls that aren't self-registering. It also goes against these instructions in the FoxPro Help file: "The setup creation program you use must create MSI setup packages using Windows Installer technology."

It doesn't say what will happen if you don't, but since you're putting files into the Windows System folder, I'm tempted to say, "You'll have DLL Hell to pay" (see the sidebar, "Bigger Than GPL, AOL, or DOJ"). On the other hand, elsewhere in the Help file it says: "As with all Visual FoxPro runtime files, [VFP7R.DLL] is installed in the Windows System folder." Take your pick. If you want to use Windows Installer technology, keep reading.

InstallShield: Giving users a choice

More is not always better. Users appreciate it when you don't clutter up an application with features they don't need. It's usually not a matter of hard disk space these days, but simply providing an easier-to-use interface. If your application has several modules but not all users need all of them, you can offer options at installation—but not if you use the Setup Wizard. I'll explain how you can do this with InstallShield Express, and point out some pitfalls to watch out for.

If you haven't worked with InstallShield Express yet, I suggest you first read Whil's "'Where is the Setup Wizard?' And Other Annoying InstallShield Questions" (FoxTalk, January 2002) and Mike Stewart's technical article, located on the VFP CD. Although the InstallShield Express PDF manual (available from the Getting Started choice in the Help View) includes a step-by-step tutorial, it's only for simple projects that don't offer optional modules.

The application I wanted to install was designed for small, non-profit fund-raising organizations. It needs to be installable by inexperienced users with no help from me. The application has two components: "Donor Relations" (a contact-management module) and "Accounting." Small organizations will want to install both modules on a single computer; larger organizations will have separate computers for each module. I needed an install package that allowed the user to install one or both modules, using a dialog such as the one in Figure 1. I'll explain some of the steps I went through to create the installation package. I'll bypass the steps that are explained in the tutorial, such as General Information or Shortcuts.

[pic]

Figure 1. What I'd like the user to see.

InstallShield calls modules Features. Since each of my application's modules has its own EXE file, I associated the appropriate files and shortcuts with their respective InstallShield Features. (I'll show how I did this in a moment.)

When you create a new InstallShield project, it will have a single Feature named "Always Install." Use this Feature for any files that need to be installed regardless of which modules the user chooses. You can't remove or rename Always Install, but that's okay since it's never visible to users anyway. For each optional module, I added a Feature (by right-clicking on Features). The Required property defaulted to No, which is what I wanted (see Figure 2).

[pic]Figure 2. Two features have been added—Donor Relations and Accounting.

Next, I associated the appropriate files with each Feature, as shown in Figure 3.

[pic]Figure 3. Select the appropriate Feature before you start creating folders and dragging files.

You don't have to designate Features before you designate Files, but it makes sense to do so. You can only drag files to a single Feature at a time. Pay attention to the contents of the Feature dropdown when you're dragging files. If two Features use the same subfolder and/or files, you'll have to add them to each Feature separately. Once you have all your files in the appropriate folders, you can use Files and Features if you need to change which ones belong to which Features.

This seemed like a good time to see what the user interface would look like, so I clicked on Test Your Release. Nothing happened! Test Your Release does nothing but show a message telling you to build before testing. So I navigated to Build Your Release. Right-clicking gave me the option to Build, Run, or Test, but Build was the only one that was enabled. After choosing Build, I was able to choose Test Run. Caution: If you make a change, your test won't reflect the change unless you build your project again first.

What I saw during the test is shown in Figure 4. This isn't what I expected!

I never even defined what should be Typical or Minimal. However, when I clicked on Custom, I saw the dialog in Figure 5. This is closer to what I expected, although I would have preferred a simple Yes/No choice. (When I discuss Advertisement, I'll explain why the third option, "Installed when required," can be confusing.) Now if I could just get rid of the first dialog.

[pic]

Figure 4. This dialog appears by default.

[pic]

Figure 5. This user wants the Accounting module but not the Donor Relations module. It's too bad that the second option is displayed even for features that have no subfeatures.

It turns out that the Setup Type dialog (Figure 4) is included by default, even if you haven't added any Features. I thought I could disable it by choosing Dialogs, but it turns out that the way to disable it is to use Setup Types to remove the first two types. You can't remove all three, but that's okay because the dialog won't appear if there's only one Setup Type.

On second thought, maybe I could use the Setup Types dialog after all. What if I changed the first button to "Donor Relations," the second button to "Accounting," and the third button to "Both"? Unfortunately, that didn't work, because no matter what you call the third Setup Type, it always displays the Feature Selection dialog (Figure 5), even if there are no Features. If you have more than two mutually exclusive options, you must use the third Setup Type. You can rename it, but you can't change its functionality, which is to display the Feature Selection dialog.

Figure 6 shows how I removed the first two Setup Types. The list of "Features to be installed for the Custom setup type" makes it look like you can uncheck a Feature that you don't want installed, but that only applies to the first two Setup Types. With the third Setup Type, the user will always be able to choose whether to install any of the optional Features. The checkmark simply determines the default state of the Feature when it's presented to the user. If you uncheck the Feature, the default will be "Not available." If you check the Feature, it will be "local hard disk," unless you'd set the Feature's Advertised property to "Yes," in which case it will be "Installed when required."

[pic]

Figure 6. Having only one Setup Type checked removes the Setup Type dialog.

There was only one step left before my installation package was finished: Merge Modules. Since my application only uses built-in FoxPro features, I only needed the ones shown in Figure 7.

[pic]Figure 7. Make sure that the appropriate Features are checked for each Merge Module.

If you look carefully, you'll notice that I only checked "Accounting" for the FoxPro runtime. I should have checked "Always Install." Caution: Check your list twice, or your package will be naughty, not nice. For users who install both modules, this mistake won't cause a problem unless they later uninstall the Accounting module. The Donor Relations module will stop working because the FoxPro runtime files will have been removed.

A final word of caution: InstallShield Express for Visual FoxPro is fairly new. If at all possible, test your installations on computers that are as similar as possible to those of your clients.

The Wise alternative

The products from Wise Solutions have long been popular with FoxPro developers who wanted something more powerful than the Setup Wizard but less expensive (and, in my opinion, easier to use) than InstallShield. There are now two Wise products that can be used for VFP 7: the Wise for Windows Installer, which, like InstallShield Express, is a wrapper for the Microsoft Windows Installer, and the Wise Installation System, which is completely independent of the Microsoft Windows Installer. For experienced Wise users (pun intended), I'll cover some of the extra steps that are required with VFP 7. I'll also explain how you can offer users the choice of installing optional modules.

Wise Installation System

If you're comfortable with Wise and aren't yet ready to tackle the Windows Installer, you can use the current version, or even its predecessor, Installmaster, to deploy VFP 7 applications. If you have the very latest update, when you get to the runtimes step, you'll see Visual FoxPro 7 listed (see Figure 8).

[pic]

Figure 8. If you don't see the Visual FoxPro 7.0 checkbox, use Files to add the appropriate runtimes listed in Table 1.

Checking the box will add the required VFP 7 runtimes, as well as a few optional components. Examine the Include file to see what's been added, and then use Table 1 to determine whether you should add any others. If you don't have the latest version, just use Table 1 to determine what files to add. Unlike the Setup Wizard, you have control over where the FoxPro runtime files are installed, so you can put them in the Windows System folder or in Program Files\Common Files\Microsoft Shared\VFP. Keep in mind, however, that you must tell Wise to register the FoxPro runtime files in case they're not in the path.

If you want to give users a choice of modules to install, add a component for each module, as shown in Figure 9.

[pic]Figure 9. After clicking Add on the Components screen, simply enter the name of your module.

Then associate the appropriate files with each component. When using components, the lower left pane of the Files display can be confusing (see Figure 10). Although it looks like a typical Explorer view of folders, some of the entries aren't actual folders.

[pic]

Figure 10. All components are shown in a single treeview display.

The first level of the tree shows the components. The next level shows Application, which stands for the folder where the user installs your program. There will only be one such folder on the target computer, even though Application is listed under every component. System32 stands for the Windows System folder on 32-bit systems. When designating the files that are to be installed, make sure you put them in the appropriate folder that's under the appropriate component.

The dialog that the user will see is similar to Figure 1.

Wise for Windows Installer

As with InstallShield Express, this product creates Windows Installer packages that use Merge Modules. However, it doesn't know what development platform you use, so you have to tell it where to look for the FoxPro Merge Modules. When you add Merge Modules for the first time, it will only show you the ones in the Wise Solutions Modules folder. To add the VFP 7 modules, you'll have to tell Wise to add another folder to its list of places to look. To do this, you click on the Directories button (see Figure 11).

[pic]

Figure 11. Click on the Directories button if you don't see the module you want.

The next dialog (Figure 12) may be a bit confusing. Its title is "Select Merge Module Directories," but the first thing you see is Project Directory. Just ignore it and click Add, which will bring up a directory browser. Choose [Program Files]\Common Files\Microsoft Shared\Merge Modules. Now when you return to the previous dialog (Figure 10), the FoxPro Merge Modules will be available for you to select. As you select each module, you'll see its destination directory listed as . You'll need to change it to an appropriate folder. The instructions make it sound like the module's predefined folder will take precedence, but I haven't found this to be the case.

[pic]

Figure 12. Click on the Add button to specify the folder that contains the module you’re looking for.

When using the Wise for Windows Installer with optional modules, you'll find it similar to InstallShield Express, but you'll have more control. For example, you can change the feature-selection dialog so that Advertisement isn't one of the options shown.

The Microsoft Windows Installer

Now that I've touched on a few features of Windows Installer, I'll briefly describe some others that you should be aware of.

DLL isolation

How many times have you been asked by an uninstall routine, "Do you want to delete SuchAndSuch.DLL, which is probably no longer needed—but on second thought maybe you should keep it just in case" (or words to that effect)? The creators of uninstallers wanted to be helpful, but they knew it wasn't really possible to keep track of how many programs were using that DLL. Well, you won't see that question if you use InstallShield Express for VFP 7, Wise for Windows Installer, or any other installer that uses the Microsoft Windows Installer. Microsoft is now confident that it can save us from DLL Hell. Of course, we have to help a little, such as testing our install packages before shipping them. In the scenario described earlier, where the FoxPro runtime files weren't properly associated with each Feature, the user wasn't even asked if it was okay to delete them.

Advertisement

If a client's CIO asks you whether she can advertise your application, she's probably not asking permission to put a banner ad on the intranet homepage. She's asking if your deployment supports the Advertisement option, which may save her staff some time.

Suppose your application is to be deployed on many workstations—probably from a server rather than a CD. Perhaps these workstations are due to be upgraded in the near future. The IT department will have to install your application now, and then again after the workstations are replaced. Some users may not even get around to using the application before they get a new workstation. If your deployment supports advertising, instead of actually installing all the files, it only creates the shortcuts. The rest of the application isn't installed until a user chooses the shortcut for the first time. This doesn't require any changes to your application because it's all handled by Windows Installer and the operating system.

Deploying Windows Installer packages on operating systems that don't support Advertisement can be problematic. In our multi-module example, if the user chooses "Install when required," then that module won't be installed—not even the shortcut. If you want to play it safe, remove the "Install when required" option from the list of choices. You have this ability with Wise, but not with InstallShield Express as far as I can tell.

Rollback

If you've sent out very many upgrades, you've probably had to deal with the situation where the computer crashes in the middle of the upgrade. The user is left with some new files and some old files, and the application won't run. To deal with this, you may have incorporated a "rollback option," something as simple as copying any files to be replaced to an "old version" folder for safekeeping. Then, if the client calls, you have him copy back those files and try the upgrade again.

With Windows Installer, this will no longer be needed, at least in theory. It tracks every change it makes, and, if an installation doesn't complete successfully, the next time any Windows Installer package runs, it offers to reverse the changes that were made by the unsuccessful run. You might wonder how a package can trigger another package it never even heard of. The answer is in the Registry. This is an example of the tight integration between Windows and Windows Installer.

Can you foresee a potential problem when Windows Installer packages and traditional installations are used on the same computer? After an unsuccessful attempt to install a VFP 7 application using Windows Installer, someone might install a VFP 7 application the old-fashioned way. The next time Windows Installer is run, it could remove the VFP 7 runtime files.

Application self-repair

If you've been developing with FoxPro for very long, you probably have several routines or utilities to repair things like corrupted indexes or DBF files. Maybe your application even checks for missing files on startup, just in case the user decided that some of your app's files were too large, thereby slowing down the computer. If you don't have such users, count your blessings.

Until now, my standard response to this situation has been, "Re-install the application and restore your data from backup." With Windows Installer, however, re-running the installation automatically gives the user a choice of Modify, Repair, or Remove. Choosing Repair, as Microsoft puts it, will "install files that are unexpectedly missing." Eventually, I imagine that our applications will invoke the Repair option from their error-handling routines.

Conclusion

Advance preparation usually pays off in every phase of application development. One thing you need to prepare for is the time it takes to create an installation package. The new Windows Installer has many powerful features, but most of us won't have time to learn them all before we deploy our next application. I've tried to give you an idea of what you can do with InstallShield Express, Wise, and the Setup Wizard. I hope you can use this as a starting point from which to investigate your deployment options.

Jim Williams has been programming in dBase and its superior derivatives since he abandoned the mainframe world in the early 1980s. His interest in the installation process is partly the result of having spent most of the past 10 years working for companies that sold inexpensive software to users who were often new to computers. Since the margins were too thin to justify hand-holding during installation, the distribution process had to be well planned. JimWilliams76543@.

Sidebar: Bigger Than GPL, AOL, or DOJ

According to Rick Anderson of Microsoft, "DLL Hell is arguably the biggest problem Microsoft faces." He divides the problem into three levels. Like Dante's Inferno, you can end up in level 1 through no fault of your own. Rick attributes this to "a rogue install program that doesn't check versions before it copies DLLs into the system directory." Although the newly installed program works fine, your program stops working because it depends on a newer version of the DLL that's been wiped out.

You can find yourself in level 2 when you encounter a DLL that's supposed to be backward-compatible, but isn't.

The third level is caused by "improvements" in the new version that have bugs.

As FoxPro developers, we've been luckier than most because our product has so much built-in functionality that we haven't had to rely as much on third-party DLLs. And FoxPro itself has always been good at maintaining backward-compatibility. But we're definitely not immune. For example, most of my applications use the DynaZIP DLLs. Apparently they're also popular with developers who use the XCOPY method of installation. I've learned to program more defensively.

The solution that Microsoft has come up is: Don't share DLLs. Since it's impossible to ensure that DLLs and their installation routines are always well behaved, and the limits on disk space and memory have practically disappeared, they recommend isolating each application along with the files it depends on. (Sort of reminds you of DOS, doesn't it?) Unfortunately, it's not as simple as putting all required DLLs in the application folder. Many existing DLLs make assumptions that lead to problems when two applications try to load two different copies in memory at the same time. The Windows System DLLs that have this characteristic will be "protected" so that they can't be replaced except by an operating system patch. In order for DLL isolation to work, the operating system, the installation package, and the developers will all have to do some things differently. Needless to say, it will take time for the new rules to be completely implemented. Just look at the contradictory advice in the FoxPro Help file regarding where to install support files.

Some see .NET as the solution. They note that the CLR (Common Language Runtime) will put an end to DLL Hell. They believe that the only tool you'll need in order to install your application is XCOPY. Unfortunately, they forget to mention that this will only work if the target machine has the proper version of the .NET Framework, which means an install routine will still be necessary. The good thing about the .NET Framework is that more than one copy can exist in memory at the same time. (From now on, Microsoft would like all developers to build components that have this side-by-side capability.) For this to work, however, Windows 98 Second Edition or higher is required, along with an installation package created with Windows Installer. This ensures that each application is associated with a separate set of runtime files (based on unique entries in the Registry, not their names, version numbers, or location).

For existing applications running on Windows 98 or Windows 2000 machines, you may be able to get some protection from DLL Hell right now. Install your support files in the application folder as well as the Windows System folder. Register the ones in the Windows System folder, but not those in the application folder. Add a file named [MyApp].exe.local to your application folder (where [MyApp] represents the name of your EXE file). This .local file can be empty. When the operating system sees this file, it will attempt to load the support files from your application folder and ignore the ones in the Windows System folder. This won't work in all situations, but it might be worth trying. (If you really want to be a hero, you may be able to fix someone else's broken application this way.)

Sidebar: References

• "The End of DLL Hell," by Rick Anderson—

• "Implementing Side-by-Side Component Sharing in Applications"—

• "Packaging and Deployment," by Wayne S. Freeze, in the February 2002 issue of .NET Developer—

• InstallShield Corporation—

• Wise Solutions, Inc.—

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download