19.4. Package Wizard

By now you've tried out the Property Scanner—a great little tool. It helps you feel more confident that you didn't miss some tiny thing during a big change that you made. And, you've used the Custom Startup Wizard to develop a cool startup to your equally cool user interface for your MDE. Now it's time to put the application in front of someone else . . . perhaps a lot of someone else's. Enter the Package Wizard.

The Package Wizard creates a Microsoft Windows Installation Package (MSI). It builds the cabinet files (CAB). It will include Windows System Register keys; it will even allow you to add your own keys to the register and to include your digital certificate if you created one. (See Chapter 20 for more information about digital certificates.) And, since it is an MSI file, you can manipulate the package with MSI Editors, such as Orca, allowing for even more customization.

You will see a similar look-and-feel between the Custom Startup Wizard and the Package Wizard. Like the Custom Startup Wizard, the Package Wizard is started from the Windows Start menu. Although the Package Wizard is a seven-step process, like the Custom Startup Wizard, after you've set up the template for a package you can rebuild the package without executing all seven steps. Again, like the Custom Startup Wizard you can also create a BAT file to build the installation package without going through the wizard.

Start the wizard from the menu option that was created when you installed the ADE. This will be something like Start | Microsoft Office | Microsoft Office Access 2003 Developer Extensions | Package Wizard.

Reminder Note: Unless you have adjusted your Macro security in Access, the wizard will not start. You will receive an error from the security check indicating the problem. (Note: Microsoft may have a digital signature with the final release that will allow you to start the wizard if you accept the digital certificate. See Chapter 20 for more information.)

The wizard starts with a welcome screen explaining all of the wonderful things that you can do with it (see Figure 19-8). Of course, you can skip this screen in the future.

You will probably notice that the screen says, "You will want to verify [the target system]." That's just another way of saying that the target system must have Microsoft Windows Installer 2.0 or later. It is also saying that the target system must be able to run the Access 2003 runtime. In other words, if the system can't run Access 2003, don't bother trying to install your application on it. You can review what these requirements mean in the Access 2003 install package.

19.4.1. Step 1: Identify the Template

Of course no matter what the target system, you can still run the wizard on your system. So the first step in the wizard is to identify whether you want to create a new template or to use an existing template. Figure 19-9 shows the template selection form.

If you select an existing template, you can run it without modification. Which means, by selecting the template and clicking Finish on this dialog box you can (again) very easily (re)create a package after you've changed the MDE, using the equally quick and easy steps given in the Custom Startup Wizard.

Since the template output of the wizard is an XML file, you can inherit an application as well as the template used for building it and the template used for packaging it (sounds like a combo meal). The Add . . . button allows you to add the inherited template for the (inherited) application from the XML file. Wow, if you kept all those references to templates straight, you have some pretty impressive focus!

19.4.2. Step 2: Define the Package to Create

In the second step in the wizard you start to specify the details about the package that you want to build. Figure 19-10 shows the second step, specifying the packaging options. The following describes the fields on the Package Wizard dialog box and how to use them.

The File to package will generally be the MDE you built using the Custom Package Wizard. You will have an opportunity to bundle additional components (files) in a later step (start thinking supersize).

The Root installation folder sets up the MSI to default the installation to that folder. As with all MSIs the user can specify the target folder. You can target the installation for all users of the target system by selecting "Program Files," "Common AppData," or "Common Files." Or, you can target to a user specific folder using "My Documents," "Desktop," or "User AppData."

Tip: If you target to one of the AppData folders, the default setting in Windows Explorer won't display the folder. The user must adjust their Windows Explorer settings to show hidden folders. This may be useful in situations where you don't want the user to browse to the file and run it from Windows Explorer. This might be the case if you have built a shortcut that includes some parameters needed when users start your application.

Note: You can adjust the target folder by editing the MSI file after the wizard is complete.

The Installation subfolder allows you to specify a folder that will hold the application.

The Example installation location will show where the application will be installed based on the information that is entered.

Include Access 2003 Runtime should be selected if you think that the target system will not have Microsoft Office Access 2003 installed.

The Destination for files generated by this wizard is a folder that will contain the installation package. Within that folder, the wizard will create a subfolder each time you build a package. To prepare your package for distribution, you will copy the contents of that subfolder to your install media, such as a floppy or CD.

You can compress the cabinet files (CAB). Of course this means a smaller package to deliver but a bit longer installation process. Additionally, you can embed the CAB within the SETUP.EXE file rather than making it a separate file in your install package. You're probably starting to see a pattern here—plenty of wizardy, but the ultimate control and decisions are left to the developer.

19.4.3. Step 3: Define the Application Startup Options

In step 3 you will tell the wizard how to build the shortcut to your application and where to put the shortcut. Figure 19-11 shows the various shortcut options. The following explains the command line parameters that can be included in the shortcut.

You may have the shortcut to your application added to the Start Menu to the user's Desktop.

Name is the name you want for the shortcut and you can include a special Icon to display for the shortcut. The icon file will be included in the installation package.

Hopefully by now you know that Access has a number of startup or command line parameters you can use when starting Access. The following table lists the parameters you can employ here along with the purpose of the parameter. To see additional parameters or more details about these parameters, type command line in Access help.

Parameter	Purpose
/runtime	Runs Access in runtime modewithout displaying the Access user interface.
/excl	Opens your database for exclusive access. (The default is shared.)
/ro	Opens your database for read-only access.
/user	Starts Access by using the specified user name.
/pwd	Starts Access by using the specified password.
/x	Starts Access and runs the specified macro. Another way to run a macro when you open a database is to use an AutoExec macro, which you can set up using the Custom Startup Wizard.
/wrkgrp	Starts Access by using the specified workgroup information file. See Chapter 16, "Database Security," for more information..
/cmd	Specifies that what follows on the command line is the value that will be returned by the Command function in your VBA code.

19.4.4. Step 4: Add Files and Registry Keys

In step 4 you can add more files to the installation package, and you can specify information for the Windows System Registry. Additional files can be installed in the root folder you specified in step 2 or in a subfolder of that folder. Figure 19-12 shows the dialog box.

If you are using a workgroup file and have selected the /wrkgrp parameter to be added to your shortcut path in step 3, you can add a windows Help File (.hlp or .chm) to your package.

Now here's a little-known fact—you have to be someone who likes to tinker with startup options to have found this one: If you create a BMP file with the same name as your database or application and put it in the same folder as your database, your BMP will display instead of the MS Access splash screen. Since you could just include the file in the list above, we suppose Microsoft included the Splash Screen option to let people know that this capability exists.

Tip: The BMP will only display for a short time. If you want it to appear that the splash screen is holding constant while your application starts, create a form in your database as your splash screen, then create the BMP from the screen capture of that splash screen form.

If your application uses the Windows Registry to control execution (for example, you store screen colors in the Registry), you can set the defaults by adding Registry Keys here. The advantage of adding them here as opposed to when your program first runs is that (heaven forbid the user decides to uninstall your application) the uninstall will remove those keys.

19.4.5. Step 5: The Installer's Experience

In step 5, you set up some parameters that control how the MicrosoftWindows Installer will perform. Figure 19-13 shows the Installer Experience box. The following explains the options.

This dialog box is about setting up how the Windows Installer will look—not about changing your application. That is, when you run the SETUP.EXE program the information entered here will tell the setup program how to run and what information to display.

The Product Name is strictly for the Windows installer so it will not change the product name within your application. The Product Name displays while your application is being installed. It is also the name that displays in the Add or Remove Programs list.

The Install Language indicates which language will display during the installation. This language must be included somewhere in the files that will be installed. So, when you specify a language you have to cache the language with your install. Notice in Figure 19-14 that Dutch has been selected for the Install Language.

To cache the language, you need to tell the wizard where to find that language. To find the language, you will likely need to go back to the install disk where the AccessRT.MSI can be found.

The Product Code and Upgrade Code could pretty much have their own chapter in this book. Essentially they amount to a unique identifier for your product. These permit your application to be unique in the Windows Registry. For a complete description of these, connect to the Internet and select the Help links on the form. These links take you the MSDN libraryWeb site to articles contained in the "Windows Installer" section.

Note: The Readme.htm file included in the Whitepapers subfolder of ADE contains more information about the Product Code and the Upgrade Code.

The Feature Information sets up information that the user sees when they select Custom install. Figure 19-15 shows how the information that is entered in Figure 19-13 will display during the install.

Obviously, you can see that the wizard allows only setting up one feature in your package. If you have many features you can modify the MSI using a MSI Editor. (Again, more control to the developer.)

Embedded Files are added to the package. These control the operation of the installer. For example, if you specify an End User License Agreement (EULA) the installer will prompt the user to accept the agreement before they can proceed with the install. If you don't specify the EULA, the user is not prompted.

The Background Image displays in the background of the installer dialog boxes when the only controls on the screen are buttons at the bottom of the screen. This is generally the first and last screen of the install. (Note: The image selected in Figure 19-15 is not the correct size. Thankfully, the Windows installer crops it to display appropriately when the application is installed.)

The Banner Image displays at the top of the installer dialog boxes when the installation dialog box has several options that the user can choose from. This provides a nice, polished touch.

19.4.6. Step 6: Set Installer Package Properties

In step 6, you identify more of the properties for information that will appear in the Add or Remove Programs feature in Windows and you set the properties that display in Windows Explorer for the MSI file of your package. Figure 19-16 shows the properties you can set.

The Add/Remove Programs Information displays when you select the Click here for support information link for your application in the Add or Remove Programs dialog box of Windows XP.

To have a better appreciation of this feature, think back. Have you ever downloaded software, installed it, and saved the install package in case you need it later? Or, have you ever gone back and looked at all the stuff you downloaded and wondered what the heck is in it? Have you ever started to install whatever it is (again) so that you could just find out what it is for?

The Windows Explorer "Properties" Information specifies what you and your user will see if you select your MSI file then display the properties of the file. This is the perfect place to enhance your professional image by entering relevant, meaningful information. Do your users the favor that you would like others to do for you.

19.4.7. Step 7: Save the Template/Create a Batch File

You have probably noticed that each of the dialog boxes have a Finish button. Clicking the Finish button on any of the dialog boxes causes the wizard to check if there are any changes to the template, prompts to save the template if there are changes, and executes the process to generate the installer package.

When you get to this step you will see the Completing Your Installer Package dialog box, as shown in Figure 19-17.

Just like the Custom Startup Wizard, in this last step you can save your template to a file that you can use the next time you use the Package Wizard. Not only that, but you can create a batch file (BAT) that you can use to run the template through the Package Wizard without even opening the wizard.

19.4.8. Step 8: (Optional) Modify Your Install Package (MSI)

The truth is, we hate to start writing about this step. Having walked you through the Package Wizard to write this chapter, we found that the wizard produced highly satisfactory results. So, why mess with success? On the other hand, we like to tinker. We don't think that we have ever bought anything that works exactly the way we want it to right off the shelf. And, knowing that many developers share that character flaw—err, trait—it is worth exploring how to make modifications to the MSI.

The example that we walked you through didn't show how to handle situations where you might have your front end (the user interface portion of your application) installed on all the clients' PCs with the back end (the tables and data) installed on a "server" computer. Of course, one way to cover that situation would be to create two install packages. The "Client" package would be installed on every computer. The "Server" package would be installed only once. But wouldn't it be nice to be able to give out one install package that leads the installer through the correct steps without requiring yet another piece of paper containing additional instructions?

And so, we have already found a reason to modifying the MSI. One way to handle this front-end/back-end situation is to add the back end as a file during Step 4: Add Files and Registry Keys. The trouble is Step 5: The Installer's Experience allows you to describe the feature information for only one feature (probably your front end). Plus, adding the back end during step 4 creates the problem of how to make the user understand that when they are running the install program, they have to install the back end first and that it must be on a "server" computer. At the very least, they need to know not to run (open) the front-end file until the back end has been properly installed.

As you can see, it would require a lot of information to adequately explain everything needed to understand how to modify the MSI. And, in fact, the ADE and related topics could be another entire book. So rather than trying to write a whole Microsoft Windows Installer package tutorial, this will get you started in the right direction in the event you decide you want to tweak your application's install package.

19.4.8.1. Tools for Tweaking

If you're going to tweak the MSI file, you'll need an MSI Editor. Microsoft provides a free one. You can get it by downloading the Windows Installer SDK from http://www.microsoft.com/msdownload/platformsdk/sdkupdate/default.htm?&gssnb=1.

Note: The Windows Installer SDK requires some Core SDK components. If you don't already have other components, the download could be as much as 1GB.

Before mentioning other places that you could go to for installer help, maybe we should start with a few tips about how to get help from Microsoft. That way if any of these links change, you will still be able to search and find the information.

You can go the Microsoft support route by telephone. Or, you can do as we have done for years: visit support on the web at: http://support.microsoft.com/default.aspx. Or, simply go to www.microsoft.com and click the Support link at the top right of the page.

When you're on the support page, at the top of the column on the left side of the page has a text box to Search the Knowledge Base— long time users refer to this as "Microsoft KB" or "MSKB" or simply "KB." Obviously, page layouts are subject to change. But, again, this gives you a good idea of where and how to find information. Type in a word or a couple of words and click the green arrow next to the text box. Provided that you've entered a word that has some meaning to MS products, you'll get plenty of information. And don't miss the Advance Search and Help option under the text box.

We typed orca in the text box and found that the second MSKB article titled "How to: Use the Orca Database Editor to Edit Windows Installer Files" led to http://support.microsoft.com/default.aspx?scid=kb;en-us;255905. Unfortunately, the article only tells you what you can do with the Orca user interface. You could figure that out on your own. On the other hand, the page contains a link to the Platform SDK. And that link is the first link that we specified above. The moral of this story is: Follow the leads. Dig, drill down, however you want to phrase it. There is typically plenty of valid, useful information available when you need it.

19.4.8.2. Tips for Tweaking

The links provided above are good places to go for information. Fortunately, the Microsoft Access Team was considerate enough to realize that we might want to tweak things or even to build our own packages. So, they included the SetupPak.mht file in the Whitepapers subfolder of the ADE. That is a good place to start to build an understanding of the components of the MSI database. But truthfully, it only barely scratches the surface. Here are a few more tips.

Here may be a reason why the MSI Editor shares its name with a type of whale (Orca). Maintaining an MSI database is a little like trying to develop a user interface by building all of the forms with VBA code. Imagine not having the Access user interface to layout your forms!

Figure 19-18 shows the MSI file generated from the steps laid out in this chapter in Orca. (db1 Backend .mdb was added after the screen shot taken in step 4.) The figure shows only one simple section of the MSI file—the files that are in the CAB file; the files that will be installed.

The left column lists the tables that control the Windows installer process. Some of them will not need to change when you customize the install. And, those that will change typically require changes to multiple tables. For example, let's say that you decide to change the setup so that it will install a front-end application and a back-end data file. There are many ways to do this. One way might be to set up the package so that the back end is installed only if the user goes through the Custom install.

To accomplish this you will have to add a Feature. Recall that you described one feature in step 5 and it was quite easy because the wizard added that feature to the MSI file. When you add the second feature things get a little more complicated. For one thing, you need to identify the feature in the Feature table. You'll enter a title and description the same as you did in step 5. But while using Orca you'll also record additional values, including Display and Level.

Display specifies the order of features in the interface and specifies if the features are displayed expanded or collapsed. Level specifies the initial installation levels of features. You can visit http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/controlling_feature_selection_states.asp. for more information.

Eventually you will discover that you can customize the install package any way that you want. But to do that, you will have to modify the following:

• The Control table to define a control the user can select

• The ControlEvent table to set the install level

• The Feature table to define the feature

• The Property table to define the install levels

This just listed a few of the changes. There are always trade-offs to be able to deliver what you want to deliver. There will always be some price to pay to have more options and more power to customize your applications. Maybe this is why there are a number of vendors who have written user interfaces to help with the installation process. Wise Solutions and InstallShield are among the better known providers of installation solution software.

The point of all this is, it would be foolish to imagine that it will be easy to customize the MSI file without using a tool designed to help you understand the components of the MSI file. So if you are going to start tweaking, here are two recommendations.

• Budget some time for it.

• Use the Package Wizard to add all the files needed in the package. The wizard will set up all the details needed in the File table (shown in Figure 19-18).

19.4.8.3. Install Chaining

One more thing you can do with the installation package is called Install Chaining. Install chaining is part of the "Office Setup Bootstrap." Does the term "Upsize" come to mind? We think that was affectionately tossed around at least during the development of the ADE tools.

Install chaining is the ability to cause additional installation packages to run at the completion of the installation of an application. You could chain to your application installation to install service packs to updated components. Or, you could use it to install the ActiveX controls or auxiliary programs (for example, DLLs) that your application needs.

Another way to use this capability is to modify the Microsoft Office installation to include installing your application. So, if you are partnering with Microsoft to resell Microsoft Office, you can use this to add on an application as a Value Added Reseller. For more information about this functionality visit http://www.microsoft.com/office/ork/2003/two/ch5/DepD02.htm.