LabVIEW Build Specifications: Relative Path Resolution in Runtime Engine

Answer

Relative paths in file I/O VIs inside a built LabVIEW executable resolve against the process current working directory, not against the folder that contains the executable. When you launch from a shortcut, the working directory is the shortcut’s “Start in” folder if set, otherwise the folder that contains the .lnk file. Launching by double-clicking the exe in Explorer sets the working directory to the executable’s folder. That difference is why a relative path that works in the IDE or when running from the project folder fails after deployment.

Consistent dependency loading is achieved by never relying on the working directory. Build an absolute path at runtime from the Application Directory and use that as the base for all relative sub-paths.

Confirmed facts

• Application Directory VI returns the folder that holds the built executable, independent of how the VI was launched.
• Build Specifications can copy data files with “Relative Path to Application Directory”, preserving the relative layout from the exe.
• LabVIEW Runtime Engine does not use IDE VI Search Path or project search paths. Dependencies must be in the application folder or referenced via explicit paths.

Likely explanation for path failures

In the IDE the current working directory is typically the project root, so a relative path like config/settings.ini appears to work. In the Runtime Engine the working directory is set by the OS launch context. A shortcut with an empty “Start in” will make the working directory the folder containing the shortcut, not the exe. Any prior file operation that changes the current directory, e.g., a File Dialog VI configured to change current directory, will also shift the base for subsequent relative paths.

Steps for this case

1. At application startup obtain the base once: Application Directory VI.
2. Build the full path with Build Path: Application Directory + your relative sub-path, e.g., config and settings.ini.
3. Use the built absolute path for all Open/Create/Read/Write file VIs and for Load DLL / Call Library Function nodes.
4. In Build Specifications, add configuration, data and external DLL files and set them to “Relative Path to Application Directory” so they are copied next to the exe with the same relative layout.
5. Avoid VIs that change the current working directory. If a File Dialog is required, disable “Change current directory”.

Verification: log Application Directory and the resolved absolute path at startup, then run the built exe directly from its folder, via a shortcut with blank Start in, and via a shortcut with Start in set to a different folder. The same file should be found in all three cases and no error 7 file not found should occur.

One diagnostic detail that changes the recommendation: do you currently use File Dialog VIs or other code that explicitly changes the current working directory? If yes, those calls must be removed or isolated, otherwise even Application Directory-based paths can be undermined by later relative operations.