LV 8.0.1 Build specs files

[Jacemdom]

Salut.

I have 2 build specs, 1 exe and 1 installer.

Here is the exe preview :

Here is the installer files :

is it possible to remove the extra copy of zlib.dll that is created in the programs files folder?

[kennoncotton]

I think you should be able to remove it but it will need to either be done in the EXE build Specification or in the Call Library Nodes for the DLL or both.

Basically the Installer builder attempts to keep all the files in the same relative place from your EXE build because we don't want to break VI linkages or change them while building the installer. It expects that you have everything configured the way you need it in the EXE build and you need to include that exact image. This works well when the EXE is built into one main destination folder and its subfolders, but can break down with items that are linked to are in folders that only share the root folder (c:\) in common, like your EXE preview shows, or the relative paths require going up several folders and then back down.

I think what is happening here is the Installer builder is adding zlib.dll to [ProgramFilesFolder]\Browser because it can't calculate a good relative path up out of there to where the EXE builder says it should go. And I'm assuming that you added zlib.dll to the [systemFolder] manually in the Installer(which is the right thing to do).

Based on the EXE preview I'm assuming you are either manually including zlib.dll in the EXE build, because it was not there or you manually changed its destination from the Support Folder to system32?

Solution A:

If you are manually including it in the EXE as a Support File I suggest removing it, because it is in the System folder the linkage to it doesn't get updated and it will be found there. And only manually including it in the Installer Build going to the System folder

Solution B:

If you are manually changing its destination in the EXE build to go to the System folder, I suggest changing the way the Call Library Nodes are configured. Since the DLL exists in the System Folder it is in the search path for the system and LabVIEW will find it there, we don't need to store a relative link to it. So go to each Call Library Node and make sure you only have the library name listed "zlib.dll" not the full path "c:\Windows\System32\zlib.dll" This will indicate to LabVIEW the DLL resides in a folder in the system search path and it won't store a relative link to it, so the EXE builder won't put a copy of it in the Support folder so it won't be part of the EXE preview or the files the EXE builder tells the Installer Builder to include. But you will have to include the DLL manually as part of the Installer Build so that it is guaranteed to be on the system the installer is run on.

Kennon

[Jacemdom]

And I'm assuming that you added zlib.dll to the [systemFolder] manually in the Installer(which is the right thing to do).

I did not add the file manually...

Based on the EXE preview I'm assuming you are either manually including zlib.dll in the EXE build, because it was not there or you manually changed its destination from the Support Folder to system32?

I manually included the file and manually changed the destination...

So go to each Call Library Node and make sure you only have the library name listed "zlib.dll" not the full path "c:\Windows\System32\zlib.dll"

Kennon

The DLL is called trough a CIN...

[kennoncotton]

I did not add the file manually...

I manually included the file and manually changed the destination...

The DLL is called trough a CIN...

Okay, I didn't think about the DLL being called through a CIN, but the intent of my response is still correct, you need to do some work further up the build chain process to fix the problem. I would say either A) don't include it in the EXE build and instead add it in the installer or B) change the where it is going in the EXE build spec and if necessary where the CIN looks for it.

A) If you don't include it in the EXE build, you'll have to manually copy the DLL on your build system to get it to work, but you could include it in the Installer to go into windows\system32 so the EXE will work on your target systems. This is the quick solution.

B) A more complicated solution but maybe more "correct" is to modify the CIN so it can find the DLL when the VI containing the CIN is used in the Run-Time Engine / an executable and put the DLL in that relative location in the EXE build instead of in system32. It would then propogate to the Installer build in that relative location.

Also I was able to reproduce the behavior of the Installer builder moving the .dll into the [ProgramFilesFolder]\Browser, but I wasn't able to have it automatically make a second copy if it in [systemFolder] with out selecting it from the project and including it there, can you tell me how to reproduce that or email me an example of code that is exhibiting that behavior.

Kennon