DLL Deployment Guide?

[Seth_K]

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

[rolfk]

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.

[Seth_K]

Rolf,

Thanks for the very thorough reply. 

The DLL in question is a .NET DLL, and is being developed in house.  I will look into using the GAC to simplify the management/deployment of the DLL for future use.  

It does have secondary DLLs that are being referenced by the main DLL.  While I know that LabVIEW doesn't copy those secondary DLLs, it hasn't really been a problem because they are all in the same directory as the main DLL and that behavior is consistent (that is, it will always not copy the secondary DLLs).  When you say "has a proper installer" do you mean just any method of getting the files into the right locations, or something more than that, like registering them in the GAC?

The problems I've been having are that if I'm looking at a VI with a constructor or method call, I can't tell if the DLL has been selected using the object browse or explicitly browsing for the DLL.  Is there any way to find that out with an already coded VI?  As in, if I have a method call in a VI, how can I find out how it is referencing the DLL?

Also, I've had problems where LabVIEW will come up with errors that read something like "LabVIEW cannot find DLL at location A, so it is using DLL at location B."  Where location A and B are the development and build directories.  What bothers me is 1. The DLL exists at both locations, so "not finding" it is worrisome, and 2. I've seen both A=development directory and B=build directory and vice versa.  That's why I'm trying to find a guide as to how LabVIEW handles DLLs and how it builds when they are referenced.  

Thanks,

Seth

[rolfk]

The method or property call does not define if the underlaying component is referenced by full path or only by name. Only the Automation Open (ActiveX) or the Constructor Node (.Net) knows about how and from where to locate the server that provides the class implementation.

As far as I'm aware there is no fool proof way of finding out if one of these nodes references the server component by path or by name. (well there is an indirect way by building an application and looking what references are included in the data directory inside the application destination).

[Seth_K]

So I figured out the source of my grief on this issue.  Mainly that LabVIEW keeps .NET assemblies loaded even after the files (projects, VIs, packed libraries) that were using them are closed, and until the LabVIEW application is closed.  

What I ended up doing was building the library I was developing into a packed library, moving it along with the Support directory from the build location to the final location, then when opening it, I would get a very peculiar warning.  Specifically, that the VI was expecting the DLL in the path it is in, but instead, it was loaded from the path that doesn't exist anymore.  I've attached a screenshot of the warning I receive when this happens.  

Thanks Rofl for your explanations.  I will try to implement your recommendations.