Advanced Page (Shared Library Properties Dialog Box)

Requires: Application Builder or Professional System

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

This page includes the following components:

• 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—Saves the stand-alone applications (EXE) or shared libraries (DLL) in a format that loads faster. To use the fast file format, ensure that the Enable debugging checkbox on the Advanced page does not contain a checkmark.
  
  The fast file format does not support applications that contain 3D graphs. 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 place a checkmark in the checkbox, the Select Project File dialog box appears and you can select an 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 select Use custom 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 whether to generate the shared library using the same style as shared libraries built in LabVIEW 2011 and earlier. Disable this checkbox to generate the shared library using the style of LabVIEW 2012 and later. If you migrate a build specification created in LabVIEW 2011 or earlier, this checkbox contains a checkmark by default. Disabling this checkbox might cause unintended errors if pre-existing code relies on the migrated build specification. 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 whether to embed a type library when you build shared libraries (DLLs). If you use TestStand or the LabVIEW Call Library Function Node, you must manually enable this option. The TestStand C/C++ DLL Adapter, LabWindows/CVI Adapter, and the LabVIEW Call Library Function Node use the type library to display a list of functions in the shared library, including the parameters and data types for the functions. 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. Enabling this option also prevents some potential deadlocks and atomicity violations while calling LabVIEW-built DLLs from LabVIEW.
  
  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 this shared library to load with future versions of LabVIEW. 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