Why do Analysis VIs need the full path to lvanlys.dll?

[GregSands]

I've noticed that all Analysis VIs contain the full pathname of the lvanlys.dll that is being called.  This means that the .lvproj file lists this fully qualified DLL filename as a dependency of the project.  This turns out to be an issue if the same project is opened in both 32-bit and 64-bit LabVIEW - the pathname changes from "Program Files (x86)/..." to "Program Files/...", and the project has a "dirty dot".  Some other VI libraries which also call DLLs located in the resource directory do not use the full path name (for example, the Vision VIs and the Wavelet Analysis VIs are two I noticed) and their dependencies are stored in the .lvproj file with the property "NI.PreserveRelativePath" set to "true".

Is there a reason why the full path is necessary, and if not, can it be removed?  I've also notice that VIs calling lvinput.dll and lvsound2.dll have a full pathname, but haven't tracked through to see which others also do, or do not.

[Rohama_K]

Hi,

Licensing and toolkit development are reasons for whether the full pathname is being used or the property "NI.PreserveRelativePath" is set to "true". There isn't a way to change it. Also, most toolkits will only work in 32-bit LabVIEW. According to this KB, as of 2009, NI Vision is the only toolkit that can be used in LabVIEW 64-bit. You maybe able to solve your dirty dot issue by mass compiling. 

[GregSands]

Hi Rohama,

What I'm talking about are the core VIs which are included in LabVIEW 64-bit.   My point is that some toolkits manage to find their DLLs in "resource" without a full path, so why can't all the core ones?

Also, I know I can save the project, but when it's in a SCC, that's not so useful.

Greg

[Christian Mergl]

Hi Greg,

As far as I know it's because of the compatibility to VXWorks (LV RT) OS. So when the .dll couldn't be found at the given path you have OS dependent search paths, e.g. ni-rt\system. And yes, at VXWorks its actually .out.

This is not the case with some TKs, since not all of them support every OS.

Hope this helps,

Christian

[GregSands]

Thanks Christian, that makes sense.  I wonder then if .lvproj files can be a little smarter, and realise that if a dependency is in the search path, then it doesn't need to have the full path stored?  Alternatively, perhaps multiple paths can be stored which are used only for a given OS (or 32/64-bit).  Just trying to think of ways that projects can not need re-saving between 32-bit and 64-bit LV.