Path of build directory showing up in EXE internal vi paths

[Thomas_robertson]

For years we've told our customers to use ActiveX to open a vi reference within our exe file.  However, a few years ago we had to turn off the Use LabVIEW 8.x File Layout and then the exe began to contain the path that our software was built from.  E.g. if building c:\ourapp\ourapp.lvproj, before changing the file layout, we could access ourapp.exe\viinroot.vi.  Now the paths to vi's in the exe would be Ourapp.exe\ourapp\viinroot.vi.  To get around this we created a virutal drive V:\ and mapped c:\ourapp to the virtual drive.  On our x64 build machine (with LabVIEW 2014 x64) thise creates an exe with the expected file path (ourapp.exe\viinroot.vi).  On our x86 build machiene, however, the path is ourapp.exe\V\viinroot.vi, which breaks the ability for our customers to use ActiveX to control our app.

What should we do?

[Johnnyg17]

Try using relative paths to reference Vis and files instead of an absolute path:

- Using Relative Paths: http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/creating_relative_paths/

- LabVIEW Example: https://decibel.ni.com/content/blogs/chris_lv/2014/09/05/understanding-relative-and-symbolic-paths-i...

[mikeporter]

Something I have done is to save what I call the inner root path in a FGV. By convention, my top level VI is always in the project directory so the first thing it does is get its own path, strip off the file name and save the remainder in the FGV. If I want to access LabVIEW files I can use that stored path as a relative starting point because below it the structure in the EXE is identical to the project directory structure.

BUT... you really shouldn't be using paths like that. In fact you may not need to if the target VI is already in memory. As with getting a VI Server reference, if the VI is in memory all you need is its name.

Mike...

[Thomas_robertson · Accepted solution]

We have solved this issue.  The root cause was cross linking to vi's outside of our source code directory.

@mikeporter: We did start to do something like that and it solved the problem in the places where we implemented that solution.  We went into the root directory where all sub-directories with sub vis reside and created a vi "get root path.vi" there which returns it's stripped path.  We then built all paths relative to that rather than relative to our exe's path.

However, there were some non-conforming places in our code which didn't build paths quite the same way and so we didn't find and fix that code.  So, we still had to solve the issue of the build directory being included. In another forum post someone desribed that LabVIEW finds all dependencies and then backs up until it finds the most common root folder and then builds the exe with files stored relative to that root.  Thus we figured out that some of the vi's in our source code were being linked elsewhere.  In particular they were linked to copies of themselves stored in our automaded build directory.  So the solution that NI proposed was to mass compile the directory of code.  Once we did that, this problem went away