Use this page of the Shared Library Properties dialog box to change advanced settings for a shared library.

This page includes the following components:

Option Description
Enable debugging

Enables debugging for the application, shared library, .NET interop assembly, or Web service.

Note Disabling this checkbox does not ensure full optimization.
  • Wait for debugger on launch—

    Sets the application, shared library, or .NET interop assembly to load but not run until the user enables it to run through the LabVIEW debugging controls. Place a checkmark in the Enable debugging checkbox to enable this option.
Use fast file format

Enter description of this checkbox here

When you enable the fast file format, LabVIEW does not use the Application Builder object cache. Therefore, stand-alone applications and shared libraries may take longer to build.
Copy error code files

Adds copies of XML-based LabVIEW error code text files from the project\errors and user.lib\errors directories to the run-time engine.

Note You must manually create an errors folder in the labview\user.lib directory to organize your error code files.
Use custom aliases file

Copies the project aliases file with the application, shared library, or .NET interop assembly. If you remove the checkmark from the checkbox, the Select Project File dialog box appears and you can select another aliases file in the project.

  • Aliases file in project—

    Specifies the aliases file to use with the application, shared library, or .NET interop assembly if you do not select Use the default project aliases file.

    • Browse Project—

      Displays the Select Project File dialog box, which you can use to select an aliases file.
Delay operating system messages in shared library

Delays operating system messages until calls to shared library functions end or until you load a modal window from the shared library.

You might choose to delay operating system messages, such as mouse or keyboard messages from the user, in order to avoid calling the same shared library file while a shared library function runs. For example, if the shared library function is called in response to the user pressing a button, the user should not be able to press the button again until the shared library function has completed.

If you load a modal window from the shared library, LabVIEW overrides this option and processes the messages to allow the modal window to become active. You cannot interact with other windows while a modal window is open. Most LabVIEW dialog boxes are modal windows.

Remove the checkmark from this checkbox if you want to process operating system messages while shared library functions run.
Include additional LabVIEW header files

Copies into the built shared library any additional LabVIEW header files that are referenced by the header file that is generated during the build process. Including additional header files allows you to use a LabVIEW-built shared library in C or another language that requires those header files.
Enable Enhanced DSC Run-Time support

This option only appears if you have the LabVIEW Datalogging and Supervisory Control (DSC) Module installed. Builds the application with the enhanced DSC Module Run-Time Engine. The DSC Module Run-Time Engine adds additional support for programmatic project library and shared variable management in applications that you build with the DSC Module.

You must place a checkmark in this checkbox in the following situations:
  • The application you want to build uses VI Server references to modify a library file programmatically.
  • The application you want to build uses the Save to Library VI.
If you do not enable the enhanced DSC Module Run-Time Engine in these two situations, LabVIEW returns error code 1055 when you run the built application, shared library, or .NET interop assembly.
Note Enabling this option increases the file size and reduces the start-up performance of the built application, shared library, or .NET interop assembly.
Use embedded version of run-time engine

(Linux) Builds the shared library using the embedded version of the run-time engine. Select this option if you want to deploy the shared library in an environment that does not require a front panel or user interface.
Generate build log file

Specifies whether to create a log file for the build. The build log file lists all files contained in the build, including subVIs you do not specify as Startup VIs or Always Included. The log file also contains general build information such as build start and end time, the build specification and project name, and any errors that occurred during the build.

  • Log file path—

    Specifies the path to save the build log file.
Use LabVIEW 8.x file layout

Specifies to use a flat file layout to store source files inside a stand-alone application, shared library, or Web service. LabVIEW enables this option by default for build specifications you load from LabVIEW 8.6 or earlier. National Instruments recommends you disable this option for applications you develop in LabVIEW 2009 or later.
LabVIEW 2011 compatibility mode

Specifies to use a flat file layout to store source files inside a stand-alone application, shared library, or Web service. LabVIEW enables this option by default for build specifications you load from LabVIEW 8.6 or earlier. National Instruments recommends you disable this option for applications you develop in LabVIEW 2009 or later.

The following table lists how each style changes the generated shared library.

LabVIEW 2011 compatibility mode LabVIEW 2012 and later
LabVIEW generates a C function name from the name of the VI and does not include the owning library hierarchy in the function name. LabVIEW generates qualified C function names for the VIs of a project. A qualified name is a name based on the owning library hierarchy of a VI in addition to the VI name. For example, if Foo.vi belongs to FooLib.lvlib, LabVIEW generates the C function name as FooLib_Foo. For projects created prior to LabVIEW 2012 that already have exported VIs, the generated function prototype names are not qualified. To generate these functions with qualified names, remove the corresponding VIs from the Exported VIs list on the Source Files page and then add these VIs back to the Exported VIs list.
LabVIEW generates generic type names, such as TD1 and TD2, for LabVIEW enum, cluster, and array type definitions. LabVIEW generates qualified type names for LabVIEW enum, cluster, and array type definitions by preserving the type name you assigned in the VI. For LabVIEW enums, clusters, and arrays that are not type definitions, LabVIEW generates more meaningful names such as int32Array, Cluster1, and Enum1.
LabVIEW does not expose enum values in the generated header file. LabVIEW exposes enum values in the generated header file.
Functions generated from VIs containing error in and error out clusters include error in and error out parameters. When LabVIEW generates a C function for a VI, LabVIEW does not export the error in and error out clusters as parameters of the new function. Instead, the return value of the function contains the error code of the error out cluster. To get or clear the error message, use the LVGetLastErrorMsg and LVClearLastErrorMsg functions, which are exposed in the extcode.h header file in the labview\cintools directory. For VIs containing multiple error out parameters, you can use the Define VI Prototype dialog box to choose which error out parameter the generated function uses to return error code information.
Include a type library for TestStand or Call Library Nodes

Specifies to use a flat file layout to store source files inside a stand-alone application, shared library, or Web service. LabVIEW enables this option by default for build specifications you load from LabVIEW 8.6 or earlier. National Instruments recommends you disable this option for applications you develop in LabVIEW 2009 or later.

You must install additional tools to embed a type library. Visit ni.com/info and enter the Info Code DownloadMSDTBuildTools to access the additional tools.
Execute VIs in private execution system

Configures LabVIEW to execute VIs in a multithreaded execution system when calling LabVIEW-built shared libraries to applications in other languages. By default, this option is enabled for new build specifications and disabled for build specifications built in LabVIEW 2016 and earlier. (NI Linux Real-Time) This option is disabled by default for Linux Real-Time targets because of potential performance jitters.

By default, this option is enabled for new build specifications. This option is disabled for build specifications migrated from LabVIEW 2016 and earlier to prevent unintended changes in behavior. For example, disabling this option prevents shared libraries that rely on single-threaded execution to execute in a multithreaded execution system, when LabVIEW-built shared libraries are called from a non-LabVIEW application.
Allow future versions of LabVIEW to load this shared library

Enables binary files to load either in the LabVIEW versions that they are built with or in the latest version of the LabVIEW Run-Time Engine installed on the machine. This option applies to stand-alone applications, shared libraries, packed project libraries, and source distributions. LabVIEW enables this option by default for build specifications you create in LabVIEW 2017 and later. For real-time applications, this option does not appear in the dialog box but the functionality is enabled by default.

You can disable this option to bind a build specification to a specific version of LabVIEW. Disabling this option prevents any changes to the performance profiles and helps you avoid unexpected problems resulting from compiler upgrades.

Building and Distributing Applications Home