Distributing Applications with the LabVIEW Application Builder

This article is part of a series on software engineering practices and tools for large application development in LabVIEW. Click here to view the list of other articles

Using the Application Builder differs significantly depending on the version of LabVIEW you are using. Refer to the LabVIEW Help for more detailed and the most up-to-date information about using the Application Builder. You can access the LabVIEW Help by selecting Help >> Search the LabVIEW Help in LabVIEW.

Software developers rarely intend for a finished application to be used only on the development computer. Applications are typically distributed to end users and other locations, which is often challenging. One option for distributing code is to purchase the full development environment for each destination PC. However, purchasing licenses is costly and often unnecessary because no further development will be done. Developers need methods for providing stand-alone executables or code modules.

Code distribution is also necessary if developers want to share copies of source code and support files. A large application may have hundreds of files associated with it - not only the code, but also supplementary files such as databases and documents. Manually gathering and packaging all of these files for distribution is a tedious job. Developers need a tool that packages all the relevant files together for easy distribution.

LabVIEW users face these types of issues - test, measurement, and control applications are nearly always deployed or distributed to a location other than the development PC. To address these scenarios, National Instruments provides the LabVIEW Application Builder, a user-friendly tool that enables LabVIEW users to create:

• Stand-alone applications which can be distributed to users. These users will need only the LabVIEW Run-time Engine and will not be able to view or change the code.
• Shared libraries so that LabVIEW code can be called from text-based programming languages such as LabWindows/CVI, Microsoft Visual C++, and Microsoft Visual Basic. Developers using LabVIEW shared libraries will be able to use the code, but will not be able to view or edit it.
• Source distributions so that packages of LabVIEW source files can be distributed to other LabVIEW developers. Specific VIs can be configured to add passwords, remove block diagrams, and apply other settings. You also can select different destination directories for VIs in a source distribution without breaking the links between VIs and subVIs.
• Installers to install applications, source files, and shared libraries created with the Application Builder. Installers can be customized to install Run-times and drivers.
• Zip files which are useful when you want to distribute a large amount of code as a single, portable file. Zip files are useful for distributing instrument drivers and select source files.

Building an Executable with the Application Builder

One of the most common uses for the Application Builder is to build stand-alone executables so this document will walk step-by-step through the process.
The LabVIEW Application Builder leverages the organization provided by the LabVIEW Project, which organizes and manages all of the files associated with an application. These files include VIs, project libraries, documentation, data files, hardware configuration and more. The Application Builder creates executables from user-specified files in a LabVIEW project (Figure 1), and individual build settings are saved as the project itself.

Once you choose to build a new application, the Application Builder user interface will open. Through this user interface, you can configure the settings to fit your specific needs. Build specifications are saved as a part of the project so you can save and reuse different build specifications for different purposes. The first step is to specify application information such as the name and destination directory of your executable. You can also add custom version information and a description of your executable.

The next step is to specify the source files in your project that you want to built into an executable. If you haven't already done so, to add source files to your project, right-click My Computer » Add » File.. and browse to the file you would like to add. Back in the Application Builder Properties, in the Source Files category, you will see a listing of all the files, folders, and libraries in a project. By highlighting these items and clicking on the blue arrows, you can specify start-up VIs which automatically open when the executable runs. You can also specify VIs you want to always include as part of your build. LabVIEW will not automatically include dynamic VIs and support files in executables, but it is easy to add these files manually. To make it easier to add large numbers of files that have been organized in the project, you can also elect to add entire folders to always be included. Adding a folder means that the contents of the folder will always be added to the build, even if the contents later change. Information on the files and folders that will compose the executable is saved as part of the build specification.

In the Destinations category, you can create custom destinations where files in your application will be stored when the executable is created. The default destinations are the application and Support Directories, but you can add custom destinations to help you organize complex sets of files to your liking. For example, you may want to create an additional directory to hold all of the support files your intended users may need to access.

After creating custom directories, you can specify source file settings for VIs and folders included in your project. You can also change specific VI properties, such as whether or not a VI has a toolbar, for each included VI or folder of VIs. For example, if you want a particular VI to function as a simple error message pop-up, you can remove the title and menu bars and make the VI modal so that the user cannot access any other LabVIEW windows until the error message is closed. You can also set destination directories, including the custom destinations you created previously, as shown in Figure 5.

In the Advanced category, you can adjust advanced properties for your executable, such as the option to enable debugging. By enabling debugging, you are including the VI block diagrams with the executable. In LabVIEW 8, you can use this feature to remotely troubleshoot an executable. Once you connect to the application over a network, you can use Highlight Execution, Probes, and other LabVIEW debugging tools to troubleshoot problematic behavior.

Once you have configured directories and files as desired, you can preview the file organization that the Application Builder will create when it builds the executable. This allows you to verify that all necessary files have been included and that your destinations and overall organization are set up correctly before you ever build the executable.

In the Icon category, you can create an icon for your executable using the LabVIEW Icon Editor. You may also select an icon file (.ico) that is already included in the project.

The Run-Time Languages category is where you can select which languages your application will support. The default setting is to support all languages—English, French, German, Japanese, and Korean. The language preferences apply to aspects of the shared library that the LabVIEW Run-Time Engine affects, such as dialog boxes and menus.

Creating an Installer

After successfully building an executable, you can create an installer that includes both the executable and supporting software. The Application Builder is capable of creating MSI installers for the Windows operating systems. Without an installer, end users would need to install the LabVIEW Run-Time Engine and required hardware drivers separately in order to be able to use the executable. In addition, they may need to configure hardware aliases and channels in Measurement & Automation Explorer (MAX). With the Application Builder, you can eliminate this need by creating a single installer that will install the Run-Time Engine, hardware drivers, and MAX configuration settings in addition to the executable itself.

You can use the MAX Configuration Import Wizard within the Application Builder to add your hardware configuration settings to your installer (Figure 9). Importing these configuration settings removes the need to manually recreate hardware settings on each target system.

The LabVIEW Application Builder is a cost-effective and streamlined tool for deploying applications. It helps the developer organize and package file systems for deployment. Installers created by the Application Builder help the end users by installing Run-Times, drivers, and hardware configuration in addition to the executable. Code distribution is simple when using the Application Builder.

Reader Comments | Submit a comment »

This is no help!
I have built a vi and I want to convert it into an executable, but for the life of me there is no step-by-step direction(s) to be found anywhere on HELP or on the NI site. This is unfortunately a common event.
- Mar 11, 2008

This document is very complicated and will not give exact result as we want. Why in previous version easy to build EXE but the latest is complicated!!
- masdi.dasuki@motorola.com - Jan 23, 2008

Issues
I too am having issues. I cant sem to get a callback function to work at all. More information is needed. Someone needs to read these messages.
- Chuck Streb, GM. chuck.streb@gm.com - Jul 20, 2007

This blows, typical NI documentation. Why is it so hard to create a EXE file?
- Jun 25, 2007

Building exe's with LV Lib VIs as subVIs - Part II
The LabVIEW Runtime Engine 8.2 that I had installed on the target PC using the installer on the distribution CD was not working with these exe's. However, it was able to run an exe on the target PC, when the exe only contains user created sub VIs (no VI Lib files). I had to create an Installer from a Project to re-install the LabVIEW Runtime Engine 8.2. After doing this the more complex exe's now run on the target PC. To all those still searching for a way to build a working exe: Good Luck!
- Dennis Kessler, Ericsson. dennis.kessler@ericsson.com - May 24, 2007

Building exe's with LV Lib VIs as subVIs - Part I
I have to agree with Ted Anderson regarding the following problem: "...by specifying the top-level vi, the sub-vis that it calls can NOT be included automatically in the compilation or source distribution?" This is a very serious omission, and the failure to properly document it is inexcusable. Note that the following _is_ successful: Running an exe on the target PC, where the exe only contains user created sub VIs (no VI Lib files). The LabVIEW Runtime Engine 8.2 was installed on the target PC using the installer on the distribution CD. I ran into the problem mentioned by Mr. Anderson when trying to build an exe that calls VI Lib files ( Histogram.vi, etc.) as sub VIs. In this case I added a re-named copy of Histogram.vi to my llb and tried to build an exe of the top level VI. (yes, I confirmed that my VI was calling the re-named VI, and that it resided in the llb.) The exe failed to run when launched on the target PC (complaining that the front panel for Histogram2.vi could not be found). Thankfully I read Mr. Andersona's comment and opened all of my sub VIs before creating the Project and building the exe. In Source File Settings I had to select a "Dynamica" for the VI Lib files, and for the one pop-up VI I had. The top level VI is selected as the a 'Top Level VIa' After doing this I was still not able to run the exe on the target PC. The final step was from Chin Lina's email thread in the NI Developer Zone: http://forums.ni.com/ni/board/message?board.id=170&message.id=226748&query.id=22454
- Dennis Kessler, Ericsson. dennis.kessler@ericsson.com - May 23, 2007

Not enough information
I agree with first comment. It does not tell you how to do what you need to do. It tells you that you CAN do it. A step by step example should be provided, along with an explanation of what needs to be exported/configured etc.
- Jeffrey Scharpf, Milwaukee Electric Tool. jeffrey.scharpf@milwaukeetool.com - Apr 18, 2007

What about sub-vis?
Am I to understand that by specifying the top-level vi, the sub-vis that it calls can NOT be included automatically in the compilation or source distribution? If not, why? Seems like that makes sense, and would obviously be of benefit to the developer. The only way I know of to specify all of the sub-vis is to meticulously/ tediously step through each and every block diagram, find sub-vis, load them, check their properties, go to the project window, find the sub-vi in the directory, and repeat the process over and over and over. Can't believe I'm the first to complain about this. What am I missing?
- Ted Anderson, CPP Wind Engineering. tanderson@cppwind.com - Mar 26, 2007

This document is OK as an introduction, but more details are needed. The documentation that ships with LV8 has very little detail about using the application builder. The term "Dyanmic VI", used to configure the application builder, is not to be found in the index or searching the documentation. Is this a sub VI? Related to reference nodes? Likewise there are very few details on making an installer.
- Frank Ogletree, Lawrence Berkeley Lab. ogletree@lbl.gov - Feb 21, 2006