====== 53 Dependencies ======

LabVIEW keeps track of all resources it needs to run a program. All the resources that a VI uses are usually called its //dependencies//. Some of these are defined explicitly (like subVIs used on the blockdiagram), others are implicit dependencies (like subVIs of the subVI used directly). 

When working with LabVIEW project files (.lvproj, see below), there is a Dependencies section that shows all the implicit resources of the code maintained explicitly in the LabVIEW project, split into three folders: ''vi.lib'', ''user.lib'', and ''Items in Memory''.

===== Paths =====

Regarding the resolution of paths, LabVIEW treats dependencies in one of the following ways:

=== Relative ===

This is the default behaviour.

=== Absolute ===

Files on different drives.

=== Symbolic ===

Many locations change with the execution environment, such as where on disk LabVIEW is installed or which user is logged in. For some of these locations, LabVIEW offers [[https://www.ni.com/docs/en-US/bundle/labview/page/symbolic-paths.html|symbolic paths]] which will be expanded at runtime to point to the corresponding location on the system it's executed on. Some examples are 

  * ''<vilib>''
  * ''<userlib>''
  * ''<instrlib>''
  * ''<resource>''


==== Resources ====

  * https://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/viewing_dependencies/
  * https://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/basics_file_paths/
  * https://zone.ni.com/reference/en-XX/help/371361B-01/lvhowto/using_symbolic_paths/
  * https://www.ni.com/docs/en-US/bundle/labview/page/symbolic-paths.html
  * https://labviewwiki.org/wiki/Symbolic_Path
  * https://forums.ni.com/t5/LabVIEW-APIs-Discussions/Exploring-the-Depths-of-the-VI-Server/td-p/3844848

---- 

===== Building =====

It is tricky to work on the source code of libraries in a project that are also at the same time dependencies of the same project itself. Those VIs will be loaded into memory, and there will be a naming conflict due to cross-linking.

In order to work around this situation, there are two possible steps to follow:

Step 1: Wrap the library's VIs in an .lvlib using a source distribution → this changes the namespace and the built .lvlib can be in memory while the source VIs are being worked on

Step 2: If working with VI Packages, in the VI Package Builder file (.vipb), ''Enable Renaming'' under ''Source File Settings''. All files will be automatically renamed during the installation of the .vip on the target system.