configuring dynamically loaded VI's search directory for both 64 and 32bit

[warren_scott]

Background:

I have an application that has been developed, built in LV2012 32bit.  It needs to run on a 32bit and 64bit machine (Win7, I understand the application itself will only ever be 32bit, but it needs to run in both environments).  The application dynamically loads a bunch of VI's which are raw vi's on disk (think just copy directory of files over from developer machine to the target machine that already has a exe running -- and just a copy, not a build of any sort).  All of these dyanamically loaded vi's at some point reference vi.lib, so I have a few things I need to do to the application to get it to work

a) within the .ini file for the running exe viSearchPath=......C:\Program Files (x86)\National Instruments\LabVIEW 2012\<<bunch of directories>>\*

b) within the VI object cache directory, I have a lvDistPath.txt file that includes C:\Program Files (x86)\National Instruments\LabVIEW 2012

This works just fine for when I deploy these files and run the application on a 64bit version of Win7.  However, when I try to run the application on a 32bit version of Win7, it breaks -- LabVIEW is installed in C:\Program Files\.... (no (x86)).

I am stuck with the dynamic loading architecture we have, and I can't start making changes to my code because it's not my code that is specifying where to find the files -- it's LabVIEW's internal searching algorithm.

What can I do (short of managing two separate .ini & .txt configuration files, one set each for x86 and 64bit and managing two separate installers) to get around this problem?

[RavensFan]

It sounds like you really don't have a problem with a 32 bit app vs. a 64 bit app.  It sounds like a problem with file paths being different on a 32 bit app on 32 bit windows vs. a 32 bit app on 64 bit windows.

Two things you could do.

1.  (Not sure this would work.)  Put 2 paths in the search directory, one for c:\program files path for 32 bit windows, and one for c:\program files (x86) for 64 bit windows.  One or the other will exist.  I don't know if something will hangup if it searches the other path that doesn't exist.

2.  Since you are dynamically loading the VI's, you should specify the path when you are dynamically loading them rather than having LV search for them.  There is a function called Get System Info in the File I/O >> File Constants palette that will return the path to the Program Files folder for you environment so that you can build on that to get to your dynamic VI path.

[warren_scott]

Tried out the 2 paths in the search directory this morning -- that works for half the problem.

However I could not get 2 paths to work in the lvDistPath.txt file that specifies where the vi object cache is for lvlib items.

Note:  I am properly specifying the path for the VI's I am loading.  The problem is the dependencies of the VI's that I am loading.  Example: if the dynamically loaded VI I am loading right now is the first one to ever call the "trim whitespace" function within lv.lib, then NI needs to go out and find "trim whitespace", which is specified as <lvlib>\xxxx\yyyy\"trim whitespace", so LV needs to know where to find it.  I guess I could also go through and change how I call EVERY subvi, but that would get really annoying fast.