LabVIEW Application Builder: Missing secondary DLLs and copy of LABVIEW.INI contents

[lvw]

does anybody know how to configure the application builder to automatically add all DLLs to an application? By default it only adds the DLLs that are directly called by a projects VI to a subfolder "data" of the executable.
If you are using a glue DLL which calls another DLL this will not be copied to the "data" subfolder. You have to copy it by hand to the application folder or "data" subfolder.

Another problem are the missing modified LabVIEW options. They will be stored in the LABVIEW.INI file in the [LabVIEW] section. It would be nice if the application builder would copy these keys to an default INI file for my application. I have to do this by hand again and again.
Each application generates its own INI file. So why don't generate a default one which ensures that the runtime engine behaves exactly the same way as the development environment?

I cannot understand why nobody at NI can fix these problems. Any suggestions?

[waldemar.hersacher]

In the installer go to the "source files" tab. Use "Add support file" to add the missing DLLs and the ini-file. Be sure to name the file and section as described in the help or user manual.
If you create an installer the files button will lead to a dialog where you can enter the location where to intall the support files.

You are right:
It should be an easy task to modify the app builder with a check box named "Copy LV ini to application".
With the DLLs it is more complicated. You can build a tree of all statically link DLLs. But dynamically linked DLLs, loaded by a call to LoadLibrary, are not detectable.

[lvw]

Thanks for your answer.

Yes, I know that I can add files manually in the app builder options.
But this task could be done automatically by the app builder. LabVIEW
is an automation tool, so I would expect that this stuff should be done
without user interaction. And by the way its the same for a very long
time now. The app builder is not one of the newest add-ons to LabVIEW.

I assume nobody at NI uses the app builder to produce own applications,
otherwise somebody would have addressed this problems in the past.

I have tried to find the DLLs called by a VI on my own, but the VI server
does not have any method to list the linked DLLs. This would be very
helpful. Does anybody know how to extract the called DLLs of a VI?

[waldemar.hersacher]

I have attached a startup VI which finds the location of the first DLL in a VI. It reads in th VI and uses Match pattern to search for .dll. You need some code to extract the name, a while loop around the Match pattern to find all DLLs in the VI and some code to eliminate the duplicates. I have seen that the name is multiple times in a VI. And further on you can expand it to scan all VIs in a folder and its subfolders.

[lvw]

Hi Waldemar,

I have checked your VI and it should work this way, but I do not like to do it this way. I have bought a expensive tool for programming/automation. And now I should use reverse engineering techniques to get a basic info about my VIs? This would be very error prone and time consuming. It would be very simple for the VI server to give me the information I would like to have. So I will wait for LabVIEW 8.0 or 8.1 ...

Does anybody know if there exists a LabVIEW wish list for new features like this? I have not found one on NIs web site.

[Dennis_Knutson]

How is LabVIEW supposed to determine which DLLs are called by another DLL? The VIs and first DLL are not in memory when the app is built. I'm not that familiar with other programming tools such as VC++. Is that able to automatically include DLLs called by other DLLs?

[waldemar.hersacher]

Hi Dennis,

normal installer packets, like Install Shield, are able to detect all DLLs which are statically linked. The reasion is that a DLL as each executable file has a PE (Portable Executable) Header at the beginning of the file. In the PE header is a table referring to all DLLs which is used by this DLL. The only exception is the case when a DLL is linked dynamically with the WinAPI call LoadLibrary or LoadLibraryEx. This way you can build a tree of all depending DLLs. VIs don't have this header. But LV can read VIs and is able to build a tree of DLLs stating with the DLLs in a Call Library Node.

I made a test:
I created a DLL in the folder G:\Projekte\ETL 2.0\DLL. The DLL is named ETLKWP.DLL. This folder is not part of the PATH environment variable.
I creatd a VI named CallDLL.vi with a Call Library Node linked to a function in ETLKWP.DLL. I stored it in G:\Projekte\LVSupport.
I used AppBuilder. CallDLL.vi is the top level. The application was named Test.exe and build in G:\Projekte\LVSupport. The files in the folder are: CallDLL.vi, Test.exe and ETLKWP.dll. The Application builder copied the DLL from its original location to the folder where the exe is. I think this is done because the original folder of the DLL is not part of the PATH environment variable.
Next I checked the Create Installer box. In the Files... Dialog the exe and the DLL are in the "Files in installation" list.

Conclusion:
The AppBuilder finds the DLLs and puts it in the Destination Directory and in the installer package when they are in a location which is not part of the PATH environment variable of the current locked in user. This makes sense because the DLLs in the PATH are found by the system.

[lvw]

Hi Dennis,

yes, Waldemar is right. Each Win32 DLL has an import and an export table which gives the OS information about which DLLs to load. As he mentioned this works not for dynamcally loaded DLLs via Win32 function LoadLibrary.

This is a basic functionality of Windows. Without this infos the OS could not work at all! Windows is nothing else than a bunch of DLLs.

There is a tool from Microsoft called "Dependency Walker" (part of Visual Studio) which shows all imports and exports of a Win32 DLL or EXE. It gives you a list of all exported functions. LabVIEW shows the same list in the Call Library Function dialog in the "function name" pull down list. So LabVIEW knows how to handle DLL function imports. Something similar must be done with the imports of a DLL to retrieve a hierachy of dependent DLLs which could be added by the app builder to the executable folder.

Stefan