Did you know you can make automated installs for your PocketPC and SmartPhone applications created with PocketBuilder? When you use a PocketBuilder project to compile your application, it automatically creates an <application_exe>_setup.ini file that can be fed to a third-party EZSetup program to create the installation executable (see Listing 1). It also creates a <application_exe>_makecab.bat file that is used to create the CAB file (see Listing 2). The project even automatically executes that file. That batch file includes a commented-out call to the EZSetup program.

There are a few steps you'll need to take before you can create the install file for a SmartPhone deploy:

1.  Obtain CabWizSP.exe: PocketBuilder doesn't provide the SmartPhone version of Microsoft's CabWiz utility (called CabWizSP.exe), which is used to create the CAB file that the install utilities use to create the install file. You'll need to download the Smartphone Software Development Kit from Microsoft's MSDN site and copy the CabWizSP.exe file from the Tools directory of that SDK into the \Support\cabwiz directory under the PocketBuilder install directory: http://msdn.microsoft.com/mobility/windowsmobile/downloads/default.aspx

2.  Obtain EZSetup.exe: EZSetup is a free third-party tool for creating install files for mobile devices based on CAB files. It's available from a number of sources, including: www.spbsoftwarehouse.com/products/ezsetup

By default, this is the utility that PocketBuilder uses to generate the install file. However, the purpose of this article is to explain how to use a different third-party tool to create that install file so you'll also need to:

3.  Obtain NSIS: The Nullsoft Installation System is an Open Source utility used to create installs for Windows as well as mobile devices. It can be obtained from: http://nsis.sourceforge.net

Fortunately, the INI file used for the install is the same regardless of which install utility you use. Sybase also provides a setup_sp.ini file (see Listing 3) and the appropriate CAB files that can be used with these utilities to install the PocketBuilder runtime. We could simply add the PocketBuilder CAB file to the list of CAB files in the INI file for our main install, but for this application I've decided to make it a separate part of the common install.

The <application_exe>_setup.ini file that the PocketBuilder project creates leaves the name of the CAB file to install as "**YOUR CAB FILES HERE***". Each time the PocketBuilder project is run, it recreates the <application_exe>_setup.ini file. So if you edit the file to include a reference to the CAB file it gets rewritten the next time you do a build/deploy using the project. Fortunately, we can change the value that PocketBuilder inserts there by default by editing the setup_template.ini file in the \Support\ezsetup directory under the PocketBuilder install directory. Replace "**YOUR CAB FILES HERE***" with "$CAB_APPNAME$.ARM.CAB" and the project will automatically include the CAB file name in the appropriate location.

What is a bit more problematic is that the PocketBuilder project also re-creates the <application_exe>_makecab.bat file each time it runs. What we'd like to be able to do is have a version where the call to EZSetup is not commented out or, as in this case, where we want to call a different utility (NSIS) after the CAB is generated. Perhaps the PocketBuilder development team would consider looking for a differing named file (i.e., my<application_exe>_makecab.bat) at the end of the generation process if it exists, and only run their default file if it isn't. Then we could make our modifications, rename the file, and be certain that it would run automatically for us.

In any event, let's go ahead and copy the <application_exe>_makecab.bat file and include the following in place of the commented-out call to EZSetup:

"C:\Program Files\NSIS\makensis.exe" /O"error.log" /V3 <application_exe>.nsi

The /O"error.log" entry indicates that we want messages from the utility logged out to an error.log file. The /V3 indicates that we want errors and warnings.

We also need to create an NSI file (the file that NSIS will process) along the lines of Listing 4. The sample is based on the NSIS for SmartPhone sample from the NSIS wiki site http://nsis.sourceforge.net/NSIS_for_Smartphone

The name entry indicates the name of the application that will appear in the Add/Remove programs listing and the various dialogs in the install. The OutFile indicates the single EXE file that will be created that the user can install from. The Installdir indicates the default location that the program will be installed on the user's computer (not his SmartPhone). The LicenseData is optional. If it's provided then the license dialog is shown, otherwise it's not displayed. If provided, it has to be a standard text file.

The Section entries indicate the items that the user will be allowed to choose to install. The SectionIn value indicates which Install Type entry will be available (e.g., Normal, Complete, and Custom). In this particular example, we've only defined one install type (Full) and have made both sections part of the full install. The File entries in a section indicate what files are to be copied to the destination directory indicated by the SetOutPath entry (which normally just points to the install directory).

The next items in the install script are the first of the instructions specifically used to handle a SmartPhone install. The script determines the location of ActiveSync by checking the system AppPath registry entry for the ActiveSync executable name. If it's not found, it exists indicating that ActiveSync isn't installed. Otherwise, it passes the name of each INI file created above to the ActiveSync program, which in turn installs it on the SmartPhone (or schedules it for install if the SmartPhone isn't currently connected).

The install script makes a few registry entries of its own to the host computer, noting the install of the application and providing the uninstall information. Finally, it prompts the user to determine if he wants to review the help file for the application. Once again, like the license file, this step is optional (Figure 1).

The NSI file also contains scripting for handling the application's uninstall. The primary thing we have to do is remove the registry entries that we made as the last step of the install and the directory we created to install the application on the host machine.

If all works well, you should see something like the following in the error.log file when you run the <application_exe>_makecab.bat file: Processed 1 file, writing output:

And an <application_exe>.install.exe file will be created (or whatever you defined the output file to be).

When the user executes that file, he will first see the license agreement (if provided). Note how a URL that was included in the text file has automatically been formatted as a hyperlink. Also note how the icon(s) provided have been included in the dialogs. That is followed by the installation type dialog (see Figure 2), which lists the components we defined earlier. That in turn is followed by the installation directory dialog (see Figure 3) after which ActiveSync attempts to install the program (see Figure 4). The last thing (at least in this sample) is the Help file viewing prompt (see Figure 5).

Conclusion
The Nullsoft Installation System (NSIS) offers an alternative to the EZSetup utility for creating installation files for your PocketBuilder applications. Because it can use most of the same files that PocketBuilder creates for the EZSetup install, NSIS can be easily integrated into the build process. In addition, NSIS lets you script the install, which provides more flexibility.