DLL Deployment Guide?

Question

I'm developing some LV code that calls some .Net DLLs, and I've run into some general hiccups regarding deployments and moving files and whatnot.  I've worked through the hiccups, but I would like to prevent them in the future.  Is there any guide for using and deploying DLLs within LabVIEW?  
Ideally the type of questions to be answered would be:
How does one determine if LV uses absolute or relative paths to point to DLL files?
What operations change the DLLs being pointed to?  
Does building a library into a packed library change the DLL path?  what else does?  
etc.
Thanks in advance,
Seth

Answer 1

The whole story is made extra complicated by the fact that DLL does not mean one single thing. You have the classic Windows DLL that exports simply functions to be called, then there is the ActiveX DLL that exports only up to 4 functions that you never should call yourself directly but let Windows COM Automation handle for you when instantiating the ActiveX objects, and last but not least .Net DLLs that do generally not export any public functions at all.
Each of these DLLs is loaded and handled by very different subsystems in Windows which have all their own complicated search paths and all.
1) classic DLL: Here you use the Call Library Node and define the DLL name/path in the Library name configuration (or as path parameter to the node). If you enter just the DLL name only, LabVIEW will pass the request simply to Windows and let it search its standard locations for it. If it is an absolute path then LabVIEW will first try to load the DLL from exactly that location and if that fails let Windows search it based on the DLL name only. Even if you only enter the name alone in the Call Library Node, LabVIEW will display the full path where the DLL was finally found, but it will only store the name alone and treat the DLL accordingly.
When building applications LabVIEW will include the DLL into the application folder  (by default a data subdirectory in your build application directory) if it is defined with a full path. If only the name was configured in the Call Library Node configuration (or you pass the DLL path to the CLN) LabVIEW will NOT include the DLL into the application folder and that will assume that any target system the application will be installed to has that DLL already installed in one of the standard Windows locations.
NOTE: When calling Windows API functions (and generally any DLL located in the sytem directoy) it is VERY important to never enter the entire path to the DLL but only enter the DLL name alone. Otherwise when building an application LabVIEW will copy the DLL into the application build and that will at least for Windows API components almost always run havoc with any system you try to run that application on.)
2) ActiveX DLLs: there is very little you can configure when using ActiveX DLLs. Supposedly if you reference an ActiveX automation server that is installed in the system LabVIEW will simply remember the ActiveX class and attempt in an application to instantiate it based on that name. If the ActiveX component isn't installed on a target system then execution of the Automation Open will fail. If you explicitedly browse to an ActiveX DLL then LabVIEW will use that path and also include that DLL in the application build (by default a data subdirectory in your build application directory).
3) .Net is similar to ActiveX except that Windows knows a so called Global Assembly Cache where globally available components should get installed. Again if you just reference a .Net object by its name from the object browse dialog then LabVIEW will assume that the according server component is a standard installation and won't attempt to copy it into the application build. On the other hand if you explicitedly browse to the .Net DLL then LabVIEW will copy it into the application build.
But in all these three scenarios even if you make LabVIEW implicitedly copy the DLL into the build application, this is no guarantee that it will just work, since the DLL could have secondary dependencies (other DLLs or system services) that need to be installed too in order for the DLL to be loadable and/or executable. Secondary dependencies are totally beyond the responsibility of any calling application and need to be solved with a proper installer for that component.
If your component is not self contained (meaning it has secondary dependencies) and doesn't have a proper installer, this is a major bug of the component and you should harass the developer rather than expecting LabVIEW to magically fix things the original developer of your component was to lazy or unable to find out.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions