One of the greatest improvements in Microsoft Office 2000 is its suitability for building applications. Several factors make Office 2000 a great development tool. First, many or all of the workstations in your organization probably have Office 2000 installed. This reduces the cost of deploying custom Office-based solutions by piggybacking on the built-in infrastructure. Second, Office 2000 offers many rich object models that target typical business tasks such as word processing, calculations, data access, e-mail, and presentations. Third, clients are likely to be receptive to solutions built with Office 2000 because the clients use and like the product. Fourth, the Microsoft Office 2000 Developer Edition (MOD) includes an add-on called the Package and Deployment Wizard. This developer tool provides professional support for deploying custom solutions.

This article introduces the MOD Package and Deployment Wizard. In particular, it examines three areas of functionality:

  • Packaging a solution for distribution
  • Deploying a packaged solution physically
  • Managing scripts so that you can save time and effort

I’ll use specific examples to demonstrate how to put the Package and Deployment Wizard to work for your applications.

Overview of the Package and Deployment Wizard
The Package and Deployment Wizard drives down the cost of custom applications by dramatically simplifying the process of deploying them. Developers can create a core set of files to install and remove custom applications. The performance of these installation files is similar to that of standard Microsoft Office applications. Therefore, the typical Office user probably already knows how to install custom applications packaged with the Package and Deployment Wizard.

The wizard offers three modes of distributing custom solutions. For employees connected via LAN (local area network), you can create a setup package on a LAN share. This provides easy access and fast installation since it operates at LAN speeds. For employees who aren’t connected to a LAN, you can package custom Office solutions for deployment over a Web—either the Internet or your company’s own intranet or extranet. On an extranet, this represents an especially cost-effective deployment strategy for distributing solutions to suppliers or current customers. In cases where LAN or Web access isn’t practical, the Package and Deployment Wizard can still deploy a custom solution on disc(s). When deploying via this route, you will mail the disk set for local installation.

The Access run-time component integrates tightly with the Package and Deployment Wizard. This component permits the operation of custom Access applications without having Access 2000 deployed on a workstation. This lowers the cost of deployment in several ways:

  • Your organization saves the cost of purchasing an Access 2000 license for every workstation that runs the custom application.
  • The IT department doesn’t have to support the installation of Access for users who won’t ever use it.
  • The Package and Deployment Wizard can automatically include the Access run-time component with the installation package for a custom solution.
  • Your organization obtains a royalty-free license to use the Access run-time component with a single license for MOD. The Package and Deployment Wizard is exclusively available with MOD.

You can also use the Package and Deployment Wizard to create installation packages for custom applications based on other Office components such as Word, Excel, and PowerPoint; however, the wizard doesn’t support Microsoft FrontPage or Microsoft Outlook. Custom solutions based on Office products other than Access must have the corresponding application installed on workstations targeted for the installation of the solution.

The Microsoft Data Engine (MSDE) is compatible with the Package and Deployment Wizard. You can distribute packages for custom applications that draw on MSDE with the wizard. MSDE is powerful for prototyping applications, as well as for building solutions for small groups that may eventually roll out to a much larger community. MOD includes a royalty-free, redistributable MSDE version. A Microsoft white paper outlines additional steps for using the Package and Deployment Wizard to deploy custom solutions that rely on the redistributable MSDE.

Developers can incorporate a custom installation package and third-party components with the help of dependency files. Dependency files pass along run-time requirements for components. The wizard needs dependency files for late-binding Office documents that are part of a custom solution. However, you don’t need dependency files for data access pages.

If you’re using a third-party component, obtain the dependency file from the component’s vendor. The Package and Deployment Wizard in the Professional and Enterprise editions of Microsoft Visual Basic 6 can create dependency files for custom components developed with VB. Create dependency files for late-binding Office documents with the MOD Package and Deployment Wizard.

The Package and Deployment Wizard contains many options. A deployment package can have a varying number of files, but there are always at least three. One essential file is the .cab file. The .cab deployment file compresses all of the application files in a custom solution. If any file is missing or stored in an inappropriate location, an application can fail. For this reason, it’s highly recommended that you test a deployment package before rolling it out. This allows you to determine if the setup correctly adds all files that are necessary for an application to run. Ideally, you should test the final deployment package on the same computer(s) that will run the installation package in the full-scale rollout.

Steps for packaging a custom application
To prepare a custom Office solution for deployment, you must begin by packaging it. This process involves specifying which files belong in an application, designating file storage locations, developing a .cab file, and creating a setup application (Setup.exe) file.

Starting the Package and Deployment Wizard
Press [Alt][F11] to open the Visual Basic Editor (VBE) window of the custom application for which you want an installation package. If the Package and Deployment Wizard is already loaded, it will appear on the Add-Ins menu. Click Wizard to open the Package and Deployment Wizard dialog box, which is shown in Figure A. From here, you can launch the Package, Deploy, and Manage Scripts operations.

If the wizard isn’t loaded, choose Add-In Manager from the Add-Ins menu. Double-click VBA Package And Deployment Wizard on the Available Add-Ins list and click OK. This loads the wizard and closes the Add-In Manager dialog box.

Figure A
The Package and Deployment Wizard dialog box lets you launch the Package, Deploy, and Manage Scripts operations.

Responding to Package dialog boxes
Click the Package icon on the wizard’s main menu to start packaging an application. You must use a script to store your selections in the remaining dialog boxes. If you haven’t created a script yet and want to start from scratch, select None. Otherwise, you must choose a previously created script. After you select the script you want to use, it populates the remaining dialog boxes with the choices from the prior script. The wizard doesn’t save any choices to a new script until you click Finish in the last dialog box.

Designate the Package Type in the second dialog box. If you want to create a setup program (namely, Setup.exe), choose Standard Setup Package. The other package type, Dependency File, is for creating a dependency file for a late-bound Office document.

The next three dialog boxes enable you to specify a folder for storing your package files as well as deciding what goes into the package. The wizard offers a suggested list of files to which you can add and subtract individual files. Use the Included Files dialog box to add the Access run-time component to the files for packaging. If you know for sure that your application will always deploy on workstations that already have Access 2000 or the Access run-time component installed, don’t include the run-time component. This shortens the time to install your package—particularly over a dial-up Web connection. The third dialog box in this sequence is for specifying the format of the .cab files. Your choices are a single file for a LAN share or multiple files for disks in various sizes from 720 KB to 2.88 MB.

The next two dialog boxes concern names. The first name enables you to assign a label to your custom setup dialog. This name appears when a user tries to load your custom package. The second dialog box enables you to designate both Group and Item names for your custom application. Unless a user changes the defaults during installation, the user invokes your application from the specified item within the Group on the Program folder in the Start menu.

The next two dialog boxes enable you to designate where to store application files and whether to share them. Most files will install to the $(AppPath) directory. By default, the wizard creates a folder in the Program Files folder to store the installed custom application files. You can manually change the location of this folder by editing the Setup.lst file that the wizard creates. One advantage of using the Packaging and Deployment Wizard is that it’s easy to remove all of the files in an application by using Add/Remove Programs in the Control Panel. Designating a file as shared allows a user to retain that file even while they remove the other files of an application.

Steps for deploying a custom application
Packaging an application is the first of two necessary steps for generating an installation package. The second step, deployment, builds on the packaging script and files developed in the first step. The results from this second step include a Setup.exe file, a .cab file, a Setup.lst file, and perhaps other selected content. Begin the second step to create a setup package by clicking the Deploy icon on the main Package and Deployment Wizard dialog box. This initiates a set of dialog boxes for gathering details.

The first two dialog boxes involve selecting scripts. In the first deployment dialog box, you can select None to build a new script from scratch, or you can choose the name of a previous deployment script to use as the starting point for a new deployment script. In the last dialog box, you’ll be able to assign a name to the new script or rename the modified existing script. The second deployment dialog box specifies which packaging script to use. Every deployment script must tie to one packaging script. On the other hand, any packaging script can relate to two or more deployment scripts. A single packaging script can serve as the basis for deployment by LAN, the Web, and disk. Each deployment scenario requires a unique deployment script, but all three can share a common packaging script.

The third dialog box enables you to specify the deployment method. The two options are Folder and Web Publishing. Selecting Folder places your .cab file(s), Setup.exe file, and Setup.lst file into a folder. You can have multiple .cab files when you choose to package for disks. Selecting Web Publishing enables you to add additional files, such as a folder of graphics to deploy along with the three setup files mentioned for Folder publishing. The next-to-last dialog box for Web Publishing, shown in Figure B, prompts you for a Destination URL and a Web Publishing Protocol for publishing the setup content. The URL is the location on a Web folder to which you want to publish the setup content. The protocol can be either FTP or HTTP Post. In this example, I publish to with the FTP protocol.

When you click Finish for the Web Publishing option, you’ll typically be prompted for the user name and password that entitles you to log on to the Web server. The wizard automatically uploads your setup files to the URL that you specified. In the case of publishing to a folder, the wizard simply copies the setup files to the designated folder. In this scenario, your setup package will always consist of just the three core setup files.

Figure B
The Web Publishing Site dialog box allows you to specify the URL where you want to publish the setup content.

Managing scripts
Clicking the Manage Scripts icon on the main Package and Deployment Wizard dialog box opens a dialog box with two tabs. This dialog box lists the packaging and deployment scripts on separate tabs. It only makes available scripts for the current VBA project. The names of the scripts match those you assigned in the final packaging and deployment dialog boxes. You can rename, duplicate, or delete any existing script. Be especially careful about deleting and renaming packaging scripts. These actions will invalidate any deployment scripts that rely on the renamed or deleted packaging scripts.

The Package and Deploy icons in the main Package and Deployment Wizard dialog box enable you to duplicate, edit, and resave under a new or old name. The Manage Scripts icon adds explicit script management capabilities, including the deleting of scripts, fast renaming, and duplicating.

The Package and Deployment Wizard doesn’t directly expose the contents of a script as a listing. You can view the script settings by clicking the Package and Deploy icons. However, many of a script’s features appear in the Setup.lst file along with others that the wizard sets automatically. These settings appear in an information file (.inf) format. Recall that Setup.lst is one of the three core setup files. Any text editor, such as Notepad, can edit it. One of the deployment samples below demonstrates how to save an application in a nonstandard location by editing its Setup.lst file.

Deployment samples
This section demonstrates how to apply the general discussion of the Package and Deployment Wizard. In particular, I’ll cover how to create the installation files for a LAN share and for a Web site. In addition, I’ll discuss a problem that can easily occur when working with data access pages and a workaround to it.

In the first example, let’s create the installation files for the sample Northwind database that ships with Access 2000. If you wish to generate the installation files for a LAN share, choose Single Cab in the Cab Options dialog box when you package the files. Accept the default locations for files in the Install Locations dialog box. This will install the Northwind application in the \Program Files\Northwind folder. Notice that this is different from the Northwind sample’s normal location in the \Program Files\Microsoft Office\Office\Samples folder. At the end of packaging, you’ll typically have a folder within the application folder that contains the core setup files (namely Setup.exe, Setup.lst, and and other selected files, as shown in Figure C. The DefaultDir setting in the Setup section of the Setup.lst file contains the location where the Setup.exe file will install the application file(s). The deployment dialog boxes copy the core files over to the deployment folder.

Figure C
The NorthwindPackage folder contains the core setup files.

Notice there’s a Support folder nested within the NorthwindPackage folder. This related folder contains uncompressed versions of the application files along with supporting files. These include the database file, data access pages, and other special files to facilitate the installation and removal of a custom application.

Users from anywhere on a LAN share can connect to the deployment folder and run Setup.exe to install the Northwind sample. This includes the Northwind.mdb file, along with several stand-alone Web pages that links in the .mdb file point to. Running Setup.exe installs the application files to the \Program Files\Northwind folder on the computer that’s running the setup application. All the forms and reports function properly, as do the tables and queries. However, the data access pages fail, and you’ll see a message indicating that the file moved from its default location. Users can browse the new location for the data access page, but that will just present a new failure message, since the page looks for the database file at its default location of \Program Files\Microsoft Office\Office\Samples. This problem can be resolved using the Field List control, but you may not care to require your users to make these two fixes.

The solution is relatively simple. Save the application in its default location instead of \Program Files\Northwind. You can do this by editing the Setup.lst file. Change the DefaultDir setting from
$(Program Files)\Northwind
$(Program Files)\Microsoft Office\Office\Samples

This adjustment will install Northwind.mdb and the data access pages in their default locations, so that the data access pages run correctly. This solution is appropriate as a general fix for installing any related files with a main VBA project file.

The steps for creating an installation set of files that deploy from the Web instead of a LAN share are very similar. In fact, you can use the identical packaging script. However, you must choose Web Publishing on the Deployment Method dialog box from the main Deploy dialog box. In addition, you have to specify a URL to save the setup files and specify an FTP or HTTP Post as the Web Publishing Protocol shown in Figure B. The sample uses the FTP protocol. You can FTP the three core setup files to your desktop for the Northwind sample installation. Before clicking Setup.exe to launch the installation, you may want to remove the sample Northwind.mdb file that ships with Access 2000. The setup file will install a new copy of Northwind.mdb and the data access pages. It will also add a Northwind item within a Northwind Group to the Programs folder on the Start menu.

Rick Dobson, Ph.D., and his wife operate a development and training consultancy. He is the author of the best-selling book Programming Microsoft Access 2000 for Microsoft Press. Rick is a regular contributor to TechRepublic and numerous computer periodicals. In addition, he has presented training sessions and seminars on Access and Web development topics in Australia, Canada, the United Kingdom, and throughout the United States. Rick is a Microsoft Certified Professional and a Microsoft Certified Trainer. You can reach Rick at either of the two Web sites that his practice maintains ( and ).

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.