Include all dlls of a project into executable

[labviewette]

Dear Community,

I am trying to maintain a relatively large code I didn't develop myself. The project is well structured and has different libraries and dlls in its different folders. I need to create an exe of that code. As a first step I tried to go the simplest way by selecting  a main vi in the application building configuration window and build the exe without any other configuration steps. One thing I don't understand is that the created data folder that contains the supported files does not contain all dlls that are part of the project. When running the exe I immediatly got the error "Resource not found" because some dlls were missing. As a result I added these dlls in the "always included" section of the application building configuration window. As a result these dlls were included in the data folder but still not all of the dlls of the project are included. The exe is starting now but I got another error in the initialization step of the exe. After debugging i found out that the cause is again a missing dll at some point.

My question now is:

How can I guarantee that all dlls of the project are included in the exe?

Thanks in advance.

[rolfk · Accepted solution]

LabVIEW only can know about DLLs that are directly called by Call Library Nodes. But these DLLs can depend on other DLLs that can depend on even more DLLs, and so on. There is no reliable way for LabVIEW to figure out these dependencies so it does not try to do it.

The software developer needs to know what DLLs depend on which other DLLs and document that. So the bad news is that you will have to investigate for each DLL, on what other DLLs it depends either by using tools like Dependency Checker or preferably read the documentation for the DLLs, although many developers forget that this is important information that belongs into the SDK documentation for a library.

[wiebe@CARYA]

---

@labviewette wrote:

My question now is:

How can I guarantee that all dlls of the project are included in the exe? 

---

I don't think you can 100% guarantee that. Unless you manually make sure yourself.

If you add the dll's to a class (and probably a library) it will be automatically included if the class\lib is used.

If the dll's are statically linked (with an absolute path) in the CLFN, I think they should also be included in the build automatically. If a relative path or just a name (User32.dll) is used, it won't be included. I'm not sure if the logic is exactly like that... When paths are specified outside the CLFN, the dll won't be included for sure (unless it's in a class\library)...

Dependencies of the dll will never be included (unless added to the class\library).

So making classes\libraries would be a solution...

[RTSLVU]

On top of what the others said, it really depends on the DLL and if that DLL needs to be "registered". I am not sure exactly what registered even means. But I do know that sometimes you can not just copy a DLL from one computer to another computer. (Well you "can" but it may not work)

For instance about half of our test stations contain an electronic load made by NHR. All of the NHR vi's rely on Nhl1_32.dll.

But I can not just "always include Nh1_32.dll" nor can I just copy Nhl1_32.dll from my development station to the target machine.

I have to run a separate installer for NHR products for this dll to be properly installed and registered on the target machine, otherwise my EXE will crash with the same resource not found error.

[zou]

It might be easier to include the dll path in the search path, not include the dll itself (not even directly called dll).

VI script should be able to find all dlls in the project.  Add their path to search path.  And remove dlls from always include list.

[rolfk]

---

@RTSLVU wrote:

I have to run a separate installer for NHR products for this dll to be properly installed and registered on the target machine, otherwise my EXE will crash with the same resource not found error.

---

For ActiveX components, that is fully expected behaviour. For classic DLLs it is an exception but can happen if the programmer tries to do some special handling.

But generally unless you know exactly what DLL dependencies you need to include in your executable build, the proper way for such DLL dependencies is to run the installer for the original package to put the DLL in a proper place. At least such an installer should be provided by the original developer if it is anything but a single self contained DLL.