LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How do I prevent the LabVIEW 7.0 compiler from creating a copy of a DLL

I am developing compiled LabVIEW code that will be called by an external DLL with fixed name and will interact with that calling DLL in order to request additional information, relay current hardware status, pass results and error codes, etc.  I've found that when I use a Call Library Function Node in order to interact with the external DLL and then compile it, the compiler in LabVIEW 7.0 (Professional version) will create an additional copy of the referenced DLL(s), by default in the /data directory under the location of the compiled code.  This initially caused problems, since when the compiled code is loaded it loads the copied DLL (which does not share memory with the previously loaded DLL), and thus variables are not being shared between the applications as I might wish.
 
I can fix the above issue by compiling my code, then manually deleting the created copy of the external DLL in the /data directory before running the application and ensuring that the location of the calling DLL is in the system environment PATH variable.  I'm concerned, however, that this process will have to be followed thousands of times each year by the people in my department who will be using this software to write their own applications.  I'd rather not have to field daily support questions regarding this issue.  Is there a method whereby LabVIEW is instructed NOT to create a copy of referenced DLLs?  The name and location of this external DLL is fixed.
0 Kudos
Message 1 of 5
(3,103 Views)
Dear WEckhoff,
 
LabVIEW automatically adds the supporting files. Generally, when you create executables LabVIEW assumes that you will distribute them to other computers. Therefore, having all supporting files is important.
In your case you are creating an executable that you are planning to run on the same PC, so you do not need an extra copy of the dll.
I will check to see if there is something that can be done about it.
 
Best regards,
Kalin T.
0 Kudos
Message 2 of 5
(3,076 Views)
 
 

Dear WEchoff,

A new feature of the Call Library Function Node VI was introduced in LabVIEW 8.2. It allows you to specify the full path to the dll you are calling. 

Unfortunately, there is no programmatic way to do that with versions 8.0 and earlier. If you are currently a member of the LabVIEW Standard Service Program (SSP),  you should have received your upgrade of LabVIEW for free.

Hope this helps!

Message Edited by Kalin T on 01-27-2007 12:45 PM

Kalin T.
0 Kudos
Message 3 of 5
(3,034 Views)
 

 


@Kalin T wrote:
 
 

Dear WEchoff,

A new feature of the Call Library Function Node VI was introduced in LabVIEW 8.2. It allows you to specify the full path to the dll you are calling. 

Unfortunately, there is no programmatic way to do that with versions 8.0 and earlier. If you are currently a member of the LabVIEW Standard Service Program (SSP),  you should have received your upgrade of LabVIEW for free.

Hope this helps!

Message Edited by Kalin T on 01-27-2007 12:45 PM


LabVIEW even before 7.0 treats DLLs that are located in the System or Windows directory differently to other DLLs. It assumes that these DLLs are part of the operating software or third party installers and does not include them in an application build.

So just place your DLL in one of these two directories and make sure you configure the Call Library Node(s) to point to this location and then building your applciation will not create a local copy of the DLL anymore.

Rolf Kalbermatter

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 4 of 5
(3,031 Views)

Thank you for your input, Rolf!

WEchoff, I hope this information helps!

Kalin T.
0 Kudos
Message 5 of 5
(3,008 Views)