dll problems on deploymet

[PaulMc]

I'm having problems with some .dll files when i deploy teststand.

The dll is stored with the source code (labview) and labview is calling the dll.

The problem occurs when the deployed system is installed, the dlls have been copied into the data folder that teststand creates, but the Labview link to dll is not updated and labview goes off hunting for the dll in the source code location which would not be there on a deployed system.

I've tried including the dll in the teststand project, but all this does is create a bogus source directory within the deployment with only the dll inside, aswell as it still being in data. looks very untidy.

The only way to solve the issue at the moment is to open the VI's once the install is complete and check the links to the dlls, this is very time consuming and a real pain, especially as i cannot be where the program is being installed all the time. it should just work!

Message Edited by PaulMc on 06-12-2007 06:00 AM

[RayFarmer]

Paul,

What teststand version are you using?

Ray

[PaulMc]

4.0

I also had this problem with 3.5 aswell.

[RayFarmer]

Hi Paul,

As a work around, can you have the dll either start in the data folder rather than the source vi's then at least the links will be the same as the deployed system.

Ray.

[PaulMc]

I've ended up creating a global in labview, with the filepath of the dll stored. Then using that global to all my dll calls for the filepath location.

I will just have to manually add the dll to the destination computer.

[AllenP]

I have a couple of questions.

1)  What version of LabVIEW are you using?

2)  Are you using a relative or absolute path to the DLL in LabVIEW?

3)  In the Image directory after you deploy, open the VI that calls the DLL.  Look inside the Call Library node.  What is the path in the VI there?

Allen P.
NI

[PaulMc]

Using labview 8.2.1

the path is specified absolute, labview will not allow any other way for dll calls.

Whats happens is that in the dll configuration panel, origianl file path for the dll

c:\source\code\directory\dllfinename.dll    - ( original file name and location).

The vi's using the dll are then used with Teststand for the test sequencing. When using the deployment tool with Teststand the links are not changed, even in the image folder.

Teststand makes a copy of the dll into the data directory, where it puts other dll's it uses for the build and program e.g. lvsounds.dll and lvanlys.dll it seems to have no trouble updating to these dlls and even one of my own thats used for something else within the program, the links are updated. So if it does it for one why not another dll??

I would expect the dll filepath to have been updated in the labview code and look something like below.

c:\adirectoryname\Teststand Deployment\image\target\data\dllfilename.dll - (Image folder)

c:\Installdirectory\data\dllfilename.dll - (after install on target system)

If you have the source code still on the computer when installing the progrom it looks like it works fine, as the dll acorrding the vi's is in the right place. Soon as its on anyother system the vi's lose the dll as they are looking in the incorrect location. The Teststand will then not run as the vi's themselves and not executable anymore.

[AllenP]

LabVIEW does allow for relative paths to DLLs.  It will use the local directory and the windows search paths to find the dll.  For example, type "user32.dll".  You will notice that the list of functions populate.

When you go to the image directory, open the VI.  Look inside the Call Library Function node.  What has the "Library name or path" been changed to?


The Deployment Utility should change all absolute paths to relative paths when deploying.  This is why it is in the data directory.  The Deployment Utility does not know where one will install the dll, so it cannot use an absolute path for this. 

Allen P.
NI

[AllenP]

Also, do you have an example that reproduces the problem?