Archived: Customizing Create Distribution Kit Installers in LabWindows/CVI

Publish Date: Apr 30, 2018 | 13 Ratings | 2.62 out of 5 | Print | 2 Customer Reviews | Submit your review

Overview

This document has been archived and is no longer updated by National Instruments.

This document describes the methods that you can use to customize a Distribution Kit created in LabWindows/CVI 6.0, 7.0, and 7.1.

For LabWindows/CVI 8.x and later, refer to Distributing Applications with the LabWindows/CVI 8.x Distribution Kit.

Table of Contents

  1. Introduction
  2. Technology Background
  3. Using the Create Distribution Kit in LabWindows/CVI
  4. Distribution Kit Layout
  5. Additional Distribution Kit Installation Tips
  6. MSI Database Modification Tools
  7. Considerations When Modifying a Create Distribution Kit Application Using a Third-Party Editor
  8. Create Distribution Kit Modification Examples

1. Introduction

This document describes the methods that you can use to customize a Distribution Kit created in LabWindows/CVI 6.0, 7.0, and 7.1.

LabWindows/CVI is a 32-bit ANSI C programming environment for building data acquisition and instrument control applications under Microsoft Windows. One of its powerful features is the Create Distribution Kit tool. The Create Distribution Kit (CDK) is a powerful, easy-to-use system for creating simple installers from which you can deploy LabWindows/CVI applications on a target machine.

The default CDK installer is sufficient to suit the development needs of most LabWindows/CVI developers. Some customers, however, have very specific distribution needs that require customization of the created installer. The purpose of this document is to provide suggestions on the best methods to accomplish these modifications. However, due to the inherent complexity of installers, National Instruments makes no guarantees on the success or consequences of using these techniques or the usefulness of these methods in future versions of LabWindows/CVI.

Back to Top

2. Technology Background

The installer generated by the CDK tool in LabWindows/CVI is based on Microsoft’s Windows Installer Technology. Microsoft developed the Windows Installer service to be a flexible, uniform installer technology across all of their Win32-based operating systems. The Installer service improves the installation and uninstallation of programs and solves common installer problems, such as shared DLL conflicts.

This technology is a native part of Microsoft Windows 2000/XP/Me and is provided in small, redistributable service packs to Windows NT/98. The Windows Installer was formerly named Microsoft Installer (MSI). The names of the Win32 API functions are prefixed with the string Msi, and the installer packages have the .msi extension.

Related Documentation

Because the CDK installer uses this standard technology through Microsoft published APIs, you can refer to the following sources for more information:

  • Microsoft Developer Network (MSDN)
  • Microsoft Windows Installer SDK
  • Various Web sites, such as http://www.installsite.org
  • Reference texts from several popular publishing houses
  • Various public Usenet newsgroups

Back to Top

3. Using the Create Distribution Kit in LabWindows/CVI

Before we discuss how to customize a distribution kit, we will briefly review what a distribution kit is used for and how to create one in LabWindows/CVI.

You can use a distribution kit to bundle and deploy applications on other computers that do not necessarily have the LabWindows/CVI development environment installed. The CDK is necessary because a LabWindows/CVI application can consist not only of a .exe and possibly a user interface resource file (.uir) but also can include other National Instrument components, such as the LabWindows/CVI Run-Time Engine, the ActiveX container, or a DataSocket module. The various Create Distribution Kit dialog boxes usually hide this complexity by automatically including the necessary components based on the options in the currently loaded project.

To create a distribution kit in LabWindows/CVI, select Build»Create Distribution Kit. You can select more options by clicking the Advanced button in the Create Distribution Kit dialog box. Further information is available for both dialog boxes in the LabWindows/CVI Help.

Back to Top

4. Distribution Kit Layout

When you create a distribution kit, LabWindows/CVI typically generates six files. These files must be present in the same directory for an install to be successful. These files are as follows:

  • instmsi.exe – The Microsoft executable that installs the Windows Installer service on Windows 98
  • instmsiw.exe – The Microsoft executable that installs the Windows Installer service on Windows NT 4.0
  • setup.exe – "Bootstrapper" executable that your user runs to install the Windows Installer service (if necessary) before the .msi is launched to begin the install
  • setup.ini – Configuration file for setup.exe
  • distfile.cab – Contains all of the files to be distributed in a compressed format
  • <projectname>.msi – The Windows Installer database file that controls the install


When modifying a LabWindows/CVI distribution, you can take two different approaches:

  1. Make changes external to the MSI database. These techniques are done without modifying the MSI file and include items such as command line options for silent installs and for controlling the default installation directory. Refer to the Additional Distribution Kit Installation Tips section.
  2. Edit the MSI database itself. The MSI contains all of the instructions for the Installer service to follow during the install process. A .msi is a binary file, constructed in the style of a traditional relational database. The .msi includes over 50 tables, foreign key columns, and several data types. While this can be quite complex, there are editing tools available from no cost up to commercial, as well as a fair amount of documentation from Microsoft and other sources. Refer to the Considerations When Modifying a Create Distribution Kit Application Using a Third-Party Editor section.

Back to Top

5. Additional Distribution Kit Installation Tips

In addition to the options in the Create Distribution kit dialog boxes, you can use several techniques to further customize and control the MSI installation process. This section focuses on changes external to the MSI database. These changes do not require any special editing tools or in-depth Windows Installer knowledge. Unless otherwise specified, these tips can be used both in LabWindows/CVI 6.0 and 7.0.

Tip 1 – Launching Applications at the End of Distribution Kit Installs

Use the Create Distribution Kit to optionally launch an executable at the end of your installation. You can do this from the main distribution kit dialog by using the Advanced button and using the Select button to choose an executable from one of your file groups. To extend this functionality, you can also choose a batch file as the executable file (.bat or .cmd). Because this batch file can contain any number of commands, including simple if/then statements and DOS commands, you can author the batch file to perform the following tasks:

  • Run more than one application. In the Advanced Distribution Kit Options dialog box, you can normally schedule one executable that is included in your distribution kit build. Using a batch file, put each application on a separate line, and each will be launched sequentially as the previous one completes. Additionally, you can run any application already installed on the target computer, as well as use any file associations that might already exist. The following sample batch file makes a directory, runs the application associated with .doc files (such as Microsoft Word), and opens the default internet Web browser to a given web page:
      mkdir C:\mycompany
     START readme.doc
     START
    http://www.ni.com
  • Cause the launched application to run asynchronously from the distribution kit installer. Normally, the distribution kit installation will wait until the launched application has exited before completing the install process. This can cause problems such as the launched application is another MSI-based installer. In your batch file, if you prefix your application name with the keyword START, the launched application will start, the batch file will continue, and the distribution kit will complete. A sample batch file might look like the following code:
      START /MAX notepad.exe readme.txt


Tip 2 – Renaming Your MSI Installation

By default, the installer created by LabWindows/CVI will have both the same name and MSI filename as the current project. You can change both names, but the latter method can differ depending on your LabWindows/CVI version.

The "name" of the installer is what appears on the title bar during the actual installation of the distribution kit, as well as what appears in the Windows Add/Remove control panel applet. You can change this name by editing the Installation Name field in the Advanced Distribution Kit Options dialog box. LabWindows/CVI saves this new name in your LabWindows/CVI project file, and the name change takes effect after you rebuild your distribution kit.

When you build the distribution kit, the filename of the .msi database file is the same as the Application Name in the Target Settings dialog box. If the Application Name field is blank, then the filename is the name of the current project. In LabWindows/CVI 7.0, you can change this project name by choosing Edit»Project. As an alternative in both LabWindows/CVI versions, you can complete the following manual steps to change the .msi file:

  • After the distribution kit is finished building, go to the Build Location directory.
  • Rename the file with the .msi extension to any name using the command line or Windows Explorer.
  • Open the file named setup.ini in a text editor and edit the line with the tag Package= to the new .msi filename. This entry tells the setup.exe bootstrapper the name of the MSI database that it needs to launch at install time.


Tip 3 – Programatically Building A Distribution Kit Using LabWindows/CVI Automation

It is possible to control much of the functionality of LabWindows/CVI, including building distribution kits, though the COM automation interface of LabWindows/CVI. This might be useful for automating a nightly build process, for example. To build a distribution kit, use the CVI_AppCreateDistributionKit function from the cvisvr.fp instrument, which is located in CVI\samples\activex\cvi.Refer to the following sample to see how to control LabWindows/CVI through its automation interface: CVI\samples\activex\cvi\cvidemo.prj.

Tip 4 – Merging in Additional Merge Modules

One of the features of the Microsoft Windows Installer technology is the use of merge modules (.msm files). The purpose of a merge module is to package together all the information and files necessary to install a particular software component. A .msm cannot be installed by itself; it must be merged into a .msi. For several reasons, the ability to include merge modules is not visible in the LabWindows/CVI user interface. However, it is still possible to cause third-party merge modules to be merged in by using the following steps:

  • Create a File Group in the distribution kit with a name of _MSMS_.
  • Include your .msm files in that file group.
  • Build the distribution kit, and the .msms will be seamlessly merged in as MSI merge modules (instead of just being included as files).

Tip 5 – Creating Registry Entries

If you need to create registry entries as a part of your distribution kit installation process, you have several options:

  • Add code to your application to create the registry entries at install or at the first run of your application. The following examples show how to run your application at the end of the install with a special command line flag to create registry entries: CVI\samples\apps\regadd\regadd.prj.
  • Use a .reg file created by the regedit.exe Windows utility. The idea is to create a batch file that will call the regedit.exe utility, which will then import the .reg file at install time. You can use the following steps:
    • Run the regedit utility, and right-click the desired registry key, select the Export option, and choose a filename such as mykeys.reg.
    • Include this .reg file in the distribution kit and set it to install in the application directory.
    • Create a batch file, add it to the distribution, and schedule it to be the Executable to Run After Setup. In the Command Line Arguments field of the Advanced Distribution Kit dialog box, enter the string %dest , which is a flag to pass the installation directory to your batch file. Refer to the help for Advanced Distribution Kit Options dialog box for more information about these flags.
    • In this batch file, add a line similar to the following: regedit.exe /S "%1\mykeys.reg"
      The /S option tells regedit to not prompt for confirmation, and the %1 will be the first command line option passed to the batch file, which will be the installation directory you set in the previous step.
  • Edit the generated installer in a third-party MSI editing tool. Refer to the Create Distribution Kit Modification Examples section for more information.

Tip 6 – Command Line Options

When you run the distribution kit on a target machine, you can use several command line options to modify the installer behavior. In the following examples, replace the text myproj.msi with the name of the .msi file in your distribution. You can use some of the simple options with the setup.exe bootstrapper utility. You can use other options only by invoking the Windows Installer engine directly. The name of the Windows Installer engine is msiexec.exe and can usually be found in the Windows\System32 directory.

The command line options include the following and can be used in various combinations:

Options Meaning
 /i to install a .msi
 /x to uninstall a .msi
 /qn for silent install/uninstall without a user interface
 /qb for a minimal user interface
 /l*v logname.txt to enable logging of the install/uninstall
 PROPERTYNAME=propertyValue to pass a property to the Windows Installer, such as overriding the default installation directory


Examples:

Action Command-Line Syntax
Installing silently (only in LabWindows/CVI 7.0) setup.exe /q
Installing silently msiexec.exe /i myproj.msi /qn
Installing with a minimal user interface msiexec.exe /i myproj.msi /qb
Installing with logging msiexec.exe /i myproj.msi /l*v logfile.txt
Uninstalling msiexec.exe /x myproj.msi
Uninstalling silently msiexec.exe /x myproj.msi /qn
Setting the default installation directory, method 1 setup.exe INSTALLDIR=C:\MyDir\foo
Setting the default installation directory, method 2 msiexe.exe /i myproj.msi INSTALLDIR=C:\MyDir\foo    

Back to Top

6. MSI Database Modification Tools

If your installation needs go beyond the command line switches and tips that have already been mentioned, then the next step is to edit the .msi file itself. The MSI database contains all of the instructions for the installer service to follow during the install process. A .msi is a binary file, constructed in the style of a traditional relational database. The .msi includes over 50 tables, foreign key columns, and several data types. When working with Windows Installer .msi files, there are two areas of focus:

  1. How to physically open and manipulate the .msi file
  2. Which table(s) to change inside of the .msi database to implement the needed modifications


Because of the inherent complexity of the Windows Installer system, item two is beyond the scope of this paper. Instead, the remainder of the document will be dedicated to discussing the tools and specifics of using this technology outside of LabWindows/CVI. For more information about modifying tables in the .msi database, refer to the sources mentioned in the Related Documentation section.

Because a .msi database is a publicly documented Microsoft format, several options exist for manipulating these files.

  • Win32 API – A rich, C-style interface exists for programmatically manipulating .msi files at the very lowest level. This option provides the most flexibility and power but is probably the most difficult to use. MSDN documents the Win 32 API at length, and the functions generally start with the string Msi. Unless you need this level of control or a C interface, this option might not be the best.
  • ActiveX Automation interface – MSDN documents the ActiveX interface for the Windows Installer subsystem. The Windows Installer SDK also includes several examples of VB scripts that demonstrate its use. You can modify the VB scripts for your own purposes.
  • ORCA – The Windows Installer SDK includes a simple GUI-based tool called ORCA, which can open, edit, or view any .msi file. ORCA is a very useful tool, best used for performing smaller edits or looking up information about the install.
  • Commercial applications – There are several commercially available installer creation tools that can modify or create Windows Installer applications. These include products such as InstallShield Software Corporation’s InstallShield, as well as Wise Solutions Incorporated's Wise for Windows Installer. Because of the inherent complexity and learning curve of the Windows Installer, it is recommended that you use one of these packages if performing extensive modifications.


National Instruments does not endorse or recommend any of these commercial products. However, Wise for Windows Installer is one of the mainstream products that has been used to successfully create and manipulate general-purpose MSI-based installers in many companies. The following examples assume the use of Wise for Windows Installer. For more information about using of this product, refer to the online help and Web site at wisesolutions.com. Other commercial products should have similar features and functionality.

Back to Top

7. Considerations When Modifying a Create Distribution Kit Application Using a Third-Party Editor

One important concept in the Microsoft Windows Installer is the use of merge modules. Merge modules are mini-MSI databases, which end in a .msm file extension. The purpose of a merge module is to package together all the information and files necessary to install a particular software component. A .msm cannot be installed by itself; it must be merged into a .msi. For example, in LabWindows/CVI, the files cvirte.msm, nimesadll.msm, and msvcrt.msm contain all of the information necessary to install and configure the full LabWindows/CVI Run-Time Engine. Normally, the CDK seamlessly merges these files at distribution kit build time, depending on the settings in the Create Distribution Kit dialog box.

IMPORTANT: When you intend to modify a Distribution Kit in a third-party editor after creating it in LabWindows/CVI, you should NOT load merge modules in LabWindows/CVI. To do this, set the Run-Time Engine Support to None from the Create Distribution Kit dialog box before you use the Build option.This is necessary so that the resulting .msi file is as fully portable as possible when imported into other installer applications.

Because the resulting installer would otherwise be missing important NI software components, you must manually merge these components through the Wise for Windows Installer. Use the following tables as a guide for which merge modules are necessary to provide specific NI components. There is a one-to-one relationship between these tables and the Create Distribution Kit dialog box options. Then use the Wise for Windows Installer to merge the necessary .msms, which are located in the redist/msm folder in your LabWindows/CVI application directory.

If using LabWindows/CVI 6.0

NI Software Component .msm files necessary
Run-Time Engine Support : Full cvirte.msm, nimesadll.msm, msvcrt.msm
Run-Time Engine Support : Instrument Driver instrsup.msm
Run-Time Engine Support : LabVIEW Real-Time cvi_lvrt.msm
Install Data Socket Support datasocketserver.msm, datasocketcore.msm, nipaths.msm, logosdll.msm,
nimesadll.msm, msvcp60.msm, msvbvm60.msm,
comcat.msm, oleaut32.msm, cwui_ocx.msm, mfc42.msm, msvcrt.msm, comctl32.msm, html winhelp.msm,logossc.msm, roboex32.msm, ninetbrw.msm,
comdlg32.msm,
opcsupport.msm, msvcirt.msm
Install NI Reports Support nireports.msm, msvcp60.msm, msvcrt.msm, mfc42.msm, comcat.msm, oleaut32.msm  
Install Low-Level Support Driver cvirte_low_level.msm
Install ActiveX Container Support activex container.msm
Install Win95 DCOM/RTE Support nidcom95.msm


If using LabWindows/CVI 7.0

NI Software Component .msm files necessary
General CDK Support (required) ivipaths.msm, nimetautils.msm
Run-Time Engine Support : Full cvirte.msm, nimesadll.msm, msvcrt.msm
Run-Time Engine Support : Instrument Driver instrsup.msm
Run-Time Engine Support : LabVIEW Real-Time cvi_lvrt.msm, msvcrt.msm
Install Data Socket Support datasocketserver.msm,mscomctl.msm, comcat.msm, oleaut32.msm, datasocketcore.msm, comdlg32.msm, logossc.msm, mfc42.msm, comctl32.msm, opcsupport.msm,
html winhelp.msm, msvbvm60.msm, roboex32.msm,msvcp60.msm, logosdll.msm, cwui_ocx.msm, ninetbrw.msm, ni_utility.msm
Install NI Reports Support nireports.msm, msvcrt.msm, msvcp60.msm
Install Low-Level Support Driver cvirte_low_level.msm
Install ActiveX Container Support activex container.msm
Install 3D Graph Control cw3dgraph_ocx.msm, oleaut32.msm, glu32.msm, opengl32.msm, msvcrt.msm, msvcp60.msm, comctl32.msm, comcat.msm, mfc42.msm, activex container.msm

Back to Top

8. Create Distribution Kit Modification Examples

The following examples show a few modifications that you can make to a distribution kit created in LabWindows/CVI. In all cases, you should start by creating the distribution kit in LabWindows/CVI, then opening the generated .msi file and using the Wise for Windows Installer in the same directory in which the .cab file is located. Remember, set the Run-Time Engine Support to None and merge in the .msms later as needed. Set all other options, such as install directories, application files, and advanced options, as usual. Refer to the online help in the Wise for Windows Installer for more information.

Notice that regenerating a new distribution kit in LabWindows/CVI overwrites all of your customizations. Therefore, you should use the Wise for Windows Installer to make any future modifications, or alternatively you should rebuild your distribution kit in another directory.

Example 1 – Changing the Logo and Introductory Text

This example explains how to change the logo and boilerplate text on the initial screen of the CDK installer.

  1. Open the CDK .msi file in the Wise for Windows Installer.
  2. In the Installation Expert view, choose the Dialogs option.
  3. Open the Welcome Dialog. You should now see the dialog open in an editor screen.
  4. Double-click the graphic, choose the graphic tab, and browse for a new image (a .bmp file of 500x312 is a good fit).
  5. To change the text, double-click the text, and make the necessary edits.
  6. Using the Merge Modules option, merge in the necessary .msms for the NI components using the above chart.
  7. Select File»Save to generate your modified installer.


Example 2 – Adding Additional Files, Shortcuts, and Registry Entries

This example explains how to add/refresh files, shortcuts, and registry entries to your installer.

  1. Open the CDK .msi file in the Wise for Windows Installer.
  2. To add a file to your installer, choose the Files option in the Installation Expert view.
  3. Choose the feature named NIFeature(n) to display your LabWindows/CVI application files at the bottom of the screen.
  4. Use the browse option to find and include the new files that you want to include in the distribution.
  5. Select File»Save to automatically reload and refresh new and existing files if they have been changed and have not been moved from their original location.
  6. To add additional shortcuts to your installer, choose the Shortcuts option in the Installation Expert view.
  7. Use the options to the right of the screen to create or modify the shortcuts.
  8. Choose the Registry option to create additional registry entries.
  9. Use the controls in the bottom half of the screen to add your registry entries.
  10. Using the Merge Module options, merge in the necessary .msms for the NI components using the above chart.
  11. Select File»Save to generate your modified installer.


Example 3 – Editing Feature Names and Turning on the Feature Tree

This example explains how to enable the select feature tree dialog and change the displayed feature names.

  1. Open the CDK .msi file in the Wise for Windows Installer.
  2. To enable the standard Windows Installer feature tree, choose the Dialogs option.
  3. Clear the checkbox on the Select Feature Dialog, and select File»Save.
  4. Recheck the box on the Select Feature Dialog, and select File»Save again.
  5. In the Setup Editor view, choose the Features option to edit the feature names, initial states, conditions, and so on.
  6. Back in the Installation Expert view, use Merge Module options to merge in the necessary .msms for the NI components using the above chart.
  7. Select File»Save to generate your modified installer.


Example 4 – Adding A License Dialog

This example explains how to add a license dialog to your installer.

  1. Open the CDK .msi file in the Wise for Windows Installer.
  2. Choose the Dialogs option.
  3. Uncheck the Readme dialog, as well as the Select Feature dialog entries.
  4. Check the box next to the License Dialog entry.
  5. In the text field that appears below, type in or import the license text you want to display.
  6. Using the Merge Modules option, merge in the necessary .msms for the NI components using the above chart.
  7. Select File»Save to generate your modified installer.

 

Back to Top

Customer Reviews
2 Reviews | Submit your review

  - Sep 18, 2007

When I build the distribution, I end up with a series of files in multiple levels of subdirectories: Volume Volume\bin Volume\license Volume\nidist.id Volume\setup.exe Volume\setup.ini Volume\supportfiles Volume\bin\dp Volume\bin\dp\DevPartDef.xml Volume\bin\dp\Distfile.cab Volume\bin\dp\Xxxxx Xxxxxx.msi Volume\supportfiles\customResource0009.dll Volume\supportfiles\merged.bin Volume\supportfiles\niPie.exe Volume\supportfiles\NISysInf.dll Volume\supportfiles\WindowsInstaller-KB893803-v2-x86.exe By some trial and error, I've found that these are not all necessary. (The .msi and .cab files side-by-side on their own seem to be sufficient). What I was hoping for was a single installer, i.e. a 'setup.exe' type file, or a .msi installer, rather than a directory full of files like CVI gives me. It is far easier to manage the distribution of a single file than a collection of files. Ok, so I could zip them up, but surely it wouldn't be too hard to get CVI to create a self extracting installer? From my point of view, the main reason for an automated installer is to make it easier for the end user. The current CVI offering provides a confusing collection of files (4 of them executable). It is arguably more straightforward to provide a bunch of dlls and a .exe file with a set of instructions for where to copy them. For internal use, I've now installed my application to a network drive, since this is simpler than trying to explain the installer to people.

Update for 8.0?  - May 23, 2007

Update for 8.0?

Bookmark & Share


Ratings

Rate this document

Answered Your Question?
Yes No

Submit