The DLL path must work:

• in the LabVIEW IDE
• in the built executable (or installed driver package)
• optionally for x86 and x64

Note: The DLL architecture must match the LabVIEW process:

• 32-bit LabVIEW uses x86 DLLs
• 64-bit LabVIEW uses x64 DLLs

DLLs may come from:

• the project repository
• a vendor installation, for example below Program Files or instr.lib

Indirect DLL dependencies (Depending DLLs, Licence Files, Copyright Files,…) must be placed alongside the main DLL and must not be renamed.

IDE/Source Code:

<Owning Entity>\
  DLLs\
    <Architecture>\
      VendorAPI.dll
      license.txt

This is valid for both working in the repo and installing into vi.lib

Built executable:

<Application Base Path>\
  data\
    DLLs\
      <Architecture>\
        VendorAPI.dll
        license.txt

Where:

• <Architecture> is x64 or x86
• <Owning Entity> is the related module, library, class, or API

The code initialising the path should:

1. detect IDE or runtime and select the base path
2. select the x86 or x64 subfolder
3. append the DLL filename
4. verify that the DLL exists

In this example, the input for the DLL is optional. If it is left unwired (ie empty), the driver Constructor determines the default path internally and automatically.

If the DLL is installed by the vendor, define the installation path in the application configuration instead of hard-coding it.

For applications supporting both x86 and x64, provide absolute paths to both DLLs as separate configuration values. The application can then select the right bitness programmatically.

DLL functionality is usually wrapped in a LVOOP class - the “DLL Class”.

Recommended architecture:

• the “DLL Class” Constructor method does not load the DLL
• the “DLL Class” allows overwriting the full path via a separate method
• optional: the “DLL Class” generates the path to the DLL internally in the Constructor method (preferred for drivers installed separately)
• optional: the calling module or API layer resolves the DLL path and hands it to the “DLL Class”
• every DLL wrapper VI wires this path to the Call Library Function Node

Indirect DLL dependencies (Depending DLLs, Licence Files, Copyright Files,…) must be placed beside the main DLL and must not be renamed.

There are three cases for adding DLLs to the LabVIEW project:

1. Single DLL: Use the usual virtual folder structure.
2. x86 and x64 DLLs with different filenames: Use virtual folders with separate architecture subfolders.
3. x86 and x64 DLLs with the same filename: Use auto-populating folders. LabVIEW may otherwise resolve both project items to the same physical file after reopening the project, which can cause the wrong architecture to be loaded. Do not rename vendor DLLs, because dependent DLLs may reference the original filename.

For case 3, the physical folders containing the DLLs must have unique names:

GI-DAQ_x86\
  VendorAPI.dll

GI-DAQ_x64\
  VendorAPI.dll

Do not use generic physical folder names such as only x86 and x64 when several modules may contain DLLs.

For cases 1 and 2, store the DLLs close to the owning entity:

<Owning Entity>\
  DLLs\
    x86\
      VendorAPI_x86.dll
      Dependency_x86.dll
    x64\
      VendorAPI_x64.dll
      Dependency_x64.dll

Then configure the build:

1. Add all required DLLs and dependencies to Always Included. When using the HSE default build specification and the DLLs are stored inside the module folder, this is already covered because the complete Modules folder is included by default.

2. In Destinations, create one destination for each architecture that must be deployed.

2a. Use a clear destination label, for example DLLs x64 or DLLs x86.

2b. Set the destination path to the corresponding folder below the support directory:

...\data\DLLs\x64
...\data\DLLs\x86

2c. Set Destination type to Directory.

2d. Enable Preserve disk hierarchy.

3. In Source File Settings, assign the DLL files or complete DLL folders to the corresponding destination.