Can I force a CVI DLL to be downloaded with a labview rt project deployment on the target?

[bdw]

Is there any method to force a CVI DLL (referenced via Call Lib Func in subVIs) to be downloaded when a labview rt project is deployed on the target, instead of having to FTP the DLL(s) to the resp (system) folder?  I have customers who just don't seem to grasp the concept and I would like to provide written documentation for an easier method, if one exists.

[rolfk]

If you have a Pharlap based target (and since you talk about CVI DLLs I assume you are using that) the deployment of DLLs should be automatic together with the VI that calls the DLL.

If the target is VxWorks I know of no method to have its shared libraries deployed automatically. But shared libraries in VxWorks are not DLLs but some sort of elf format shared libraries, with the extension .out. And last time I looked the only way to create them was to use the VxWorks development environment (which costs money) or the GCC based VxWorks command line based toolchain (which is free). 

[bdw]

Yes, thanks, mine is a Pharlap/x86 target.  So far I have been unsuccessful in forcing the LabVIEW application builder to attach my underlying CVI DLL as anything more than a reference in the build.  If I FTP the DLL to the target manually, everything is fine.  I'm looking for a shortcut that will at least automatically include the DLL in the project/target "deploy all" or "deploy" action, but my ultimate goal is to incorporate the CVI DLL into the executable to eliminate the necessity of DLL FTP to target.  I have not found any NI LVRT documentation that addresses this; doesn't mean there isn't any, just means I haven't found it yet...

[NAKeel · Accepted solution]

Are you including your dll in your project?  If it is in your project you have the option to put the dll in the always included section of the build.  This will include it as part of the executable and you shouldn't have to ftp it over.  I tested this and the dll was added to the build when I tried it.  Where does the dll appear in the project?  Is it listed explicitly under the target, or is it listed under dependencies?

[bdw]

Thanks, yes, I just determined late yesterday that I had to include the file explicitly in the project and not assume it is included just because it is listed in the dependencies section.  That resolved the problem with "my" DLL.  My customer across the globe's issue was with the fact that CVI_LVRT.DLL is not installed on the target by default.  I guess I have it all straight now; however, there must be some sort of white paper or LVRT thread that discusses the requirements for the use of DLLs with a startup RT application and the requirement to include CVI_LVRT.DLL in your project... does anyone know of any?

The online help doesn't address the requirements for including cvi_lvrt.dll in the project at all...

[Jarrod_S.]

I do know that the issue can be a little tricky. Even if you could get the list of all your DLLs dependent DLLs and their dependent DLLs, you shouldn't simply include all them automatically. One reason is that many of these DLLs will end up depending on Windows core DLLs such as kernel32.dll. You don't want to deploy this library to RT, because PharLap already has its own shared library with its set of win32-compatible functions that isn't called kernel32.

[bdw]

While I certainly understand the necessity to discorage all DLL imports into an LVRT project, it seems CVI_LVRT.DLL is a required library for any RT application in which an underlying CVI DLL is used (if not please explain).  My preference would be to refer customers to a specific NI document/help reference describing the requirements for the use of CVI DLLs with LVRT; otherwise, I am forced to document the requirement in my product user's manual, which hardly seems the forum for it (if I don't document the requirement in my manual or have a reference to the NI site for it, I have to deal with it as a support issue, which I would like to avoid).  I figure I can't be the only developer out there whose LVRT product includes a CVI-built DLL, and we could all benefit by a single point of documentation regarding RT target requirements that is actively maintained as LabVIEW grows in use.  OK, now it just sounds like a rant... UNCLE.

[rolfk]

Well it does sound like a bit of a rant. 

After all these things are discussed in the LabWindows CVI online reference manual in the section about creating LabVIEW realtime DLLs. At least they used to be in the manual in the versions for CVI 7 and 8.