The following list describes some of the caveats and recommendations to consider when you prepare files for build specifications and distribute builds such as source distributions, stand-alone applications, or shared libraries. Windows If you also are building an installer, consider the installer caveats and recommendations.
Preparing Files for Build Specifications
- Save changes to VIs in memory before you create or edit a build specification to ensure that the preview is accurate.
- Make sure that the settings in the VI Properties dialog box are correct. For example, you might want to configure a VI to hide scroll bars, or you might want to hide the buttons on the toolbar.
- Windows If a VI includes a MathScript Node, remove any unsupported MathScript functions from your scripts.
- Windows If a VI includes a MathScript Node, add any files with a .m extension that are referenced in the MathScript Node to the project before you create or edit a build specification. If you make changes to the original .m files, you must rebuild the stand-alone application or shared library in order for these changes to be included.
- Windows If a VI includes a MathScript Node that calls functions from the libraries class, add the DLL and the header file to the project before you create or edit a build specification. Also make sure that the paths to these files are correct in the application. For example, if you build header.h into an application, its path is C:\..\Application.exe\..\header.h, where C:\..\Application.exe represents the path to the application and its filename.
Configuring Build Specifications
- If a VI loads other VIs dynamically using the VI Server or references a dynamically loaded VI through Call By Reference Nodes, you must add the dynamically loaded VIs to the Dynamic VIs and Support Files listbox on the Source Files page of the Application Properties dialog box for an application, or to the Dynamic VIs and Support Files listbox on the Source Files page of the Shared Library Properties dialog box for a shared library.
- If a VI loads other VIs dynamically using the VI Server or references a dynamically loaded VI through Call By Reference Nodes, make sure the application or shared library creates the paths for the VIs correctly. When you include the dynamically loaded VIs in the application or shared library, the paths to the VIs change. For example, if you build foo.vi into an application, its path is C:\..\Application.exe\foo.vi, where C:\..\Application.exe represents the path to the application and its filename.
- If a VI uses the Current VI's Path function, make sure the function works as expected in the application or shared library. In an application or shared library, the Current VI's Path function returns the path to the VI in the application file and treats the application file as an LLB. For example, if you build foo.vi into an application, the function returns a path of C:\..\Application.exe\foo.vi, where C:\..\Application.exe represents the path to the application and its filename.
- If you place a checkmark in the Use the default LabVIEW Configuration file checkbox on the Advanced page of the Application Properties dialog box, an error might occur if a user is running the LabVIEW Web Server and tries to run the application at the same time because they share the same port. If a user tries to run VI Server at the same time as the application, VI Server does not run and the user receives no warning that the port is already in use.
- Windows If a VI includes a MathScript Node, you must place a checkmark in the Enable MathScript support checkbox on the Advanced page of the Application Properties dialog box for an application or on the Advanced page of the Shared Library Properties dialog box for a shared library.
- Windows If a VI includes a MathScript Node that calls functions from the libraries class, add the DLL and the header file to the Dynamic VIs and Support Files listbox on the Source Files page of the Application Properties dialog box.
Distributing Builds
 | Note Do not distribute the LabVIEW product documentation. The LabVIEW product documentation is copyrighted material. |
Considerations for the LabVIEW Run-Time Engine
- The LabVIEW Run-Time Engine must be installed on any computer on which users run the application or shared library. You can distribute the LabVIEW Run-Time Engine with the application or shared library. Windows You also can include the LabVIEW Run-Time Engine in an installer. You must log on as an Administrator or a user with administrator privileges to run an installer you build using the Application Builder. Linux When you install the LabVIEW Run-Time Engine on a target computer where you want to run an application that uses the Analyze VIs, enter yes when prompted to install the LabVIEW Run-Time Engine Analysis Support package (labview80-rte-aal-1.1.rpm).
- Some VI Server properties and methods are not supported in the LabVIEW Run-Time Engine. Avoid using these properties and methods in the VIs you include in an application or shared library.
- Incorporate error handling into the VIs of the application because LabVIEW does not display automatic error handling dialog boxes in the LabVIEW Run-Time Engine.
- If the VI uses custom run-time menus, make sure the application menu items that the VI uses are available in the LabVIEW Run-Time Engine.
- When you close all front panels in an application, the application stops. If the VI you build into the application contains code that executes after the last front panel closes, this code does not execute in the application. Avoid writing block diagram code that executes after the last front panel closes.
- If you reference a VI in an application using the Call By Reference Node, if a VI uses Property Nodes to set front panel properties, or if a front panel appears to users, do not place a checkmark in the Remove Panel checkbox for that VI from the VI Settings section on the Source File Settings page of the Application Properties dialog box. If you remove the front panel, the Call By Reference Node or Property Nodes that refer to the front panel will return errors that might affect the behavior of the application.
Using Shared Variables in Stand-Alone Applications or Shared Libraries
If you plan to distribute a stand-alone application or shared library (DLL) that uses shared variables, do not include the .lvlib file in an LLB, the executable, or the DLL. Use the Source Files Setting page of the Application Properties dialog box or the Source Files Setting page of the Shared Library Properties dialog box to change the Destination of the .lvlib file to a destination outside the executable, LLB, or DLL.