built application doesn't 'see' user.lib?

[sjn]

New AppBuilder user here.

I seem to be having a problem building a standalone application that has a few custom VIs in it.  Debugging showed that it apparently refuses to recognize the custom VIs in my user.lib folder.  I tried disabling them in my source and recompiling, and the rest of it works fine.  Two are VIs in their own right, the third is a VI called from within an .LLB file, again in the user.lib folder.  None of the custom VIs contain any 'custom pieces' from elsewhere.

I'd built an installer to get the runtime engine, support files, &etc. on the target laptop and it apparently properly installed all these components.  Then I built the *.EXE separately.  No errors.

As a sanity-check, I built an EXE from another VI that uses only Labview-native VIs &etc. (i.e. nothing from the user.lib folder), 'ported it over to the target laptop, and it works perfectly.  I can only surmise that the EXE isn't properly 'seeing' stuff in the user.lib folder on the target machine.  The crashing EXE _does_ work properly on the source machine.

I'd even tried (seen in another forum posting) saving the source with the 'duplicate hierarchy' option set and building from _that_ copy.  No good.

The crashing EXE gives me the error: "Error -2147221164 occurred in class not registered in app.vi" on the laptop.  Googling this error number seems to show that it is an OS error number, with several ni.com-related postings which do not seem to apply to my situation.

Sound familiar to anybody?  I'm stumped.  Thanks for any help.

[GerdW]

Hi sjn,

when building an executable all subvis in the hierarchy of the main vi are included in the exe - including vis from user.lib.

So what do you mean by "refuses to recognize the custom VIs in my user.lib folder"? What dou you mean by "Two are VIs in their own right, the third is a VI called from within an .LLB file"? Calling by inclusion as subvi? Calling by vi server?  Please explain "isn't properly 'seeing' stuff"! What isn't proper?

When calling by vi server do you know that paths change in an executable?

[sjn]

Hi GerdW,

Yes, I would have thought everything was included in the build too.

To me, it seems like the three VIs I'd written that I'm using are crashing the EXE on the laptop.  I can pull 'disable' structures around them, build the EXE again and put it on the laptop and everything else in the VI works fine (the three VIs are math-related and, now just output zero values to the data file, but let everything else in the VI function).

As I said: two of them are *.VI files and the third is a .VI inside a *.LLB file.  They are all IN the C:\Program Files\National Instruments\Lab VIEW 8.5\user.lib\ folders on both machines but it seems the build recognizes them on the source machine but NOT the laptop.

Nope - not doing any vi server stuff: everything is called directly and these are all standalone machines.  I've even copied the VI out of the LLB right into the user.lib folder (and properly updated the source) and get the same results.  Everything called from vi.lib works fine on both machines but stuff called from user.lib only works on the source machine.

I could understand it if the stuff wasn't IN the folder but they're identical.  After seeing the first time that things weren't recognized (running the installer I'd created, then the EXE) I physically brought over the entire user.lib folder from the source machine to the laptop, so I _know_ they're the same.

Thanks for your response - I appreciate any and all help.  This is the first time I've had problems building an EXE and, coincidentally, the first time I've done a build incorporating stuff from user.lib.  My next troubleshooting move will be to hardwire the contents of the offending sub-VIs directly into the main VI and see if it helps (as messy as it will look...).

___

 6.1, 7.1, 8.5 on Windows, 7.1, 8.6 on OSX

[Dennis_Knutson]

There should be no problem using VIs in a user.lib or any other location. You mention using some math functions. What functions are you calling. Did you create an installer and run that? That is usually a requirement. Never assume that everything is included in the run-time engine. After you built the exe, was there a data folder created? Many analysis functions require the lvanlys.dll.

[sjn]

hi Dennis,

Yeah - SHOULD be...  🙂  Just simple functions in the VIs: +/*-, a couple trig functions, indexing values out of a 1D array, shuffling an array.  Nothing really weird.  The functions are all used individually in other parts of the VI and seem to have no problems.  Yes, I'd initially created an installer and ran that - it put the necessary VIs and the LLB in the user.lib folder.  It was LATER that I cloned the entire folder from one machine to another just to see if it'd make a difference.  It didn't, so I went back to just the contents created by the installer.

Yes, lvanlys.dll is in the \data\folder in the package.  I'm in the midst of 'exploding' the suspect VIs into the main VI to see if they work - the VIs were only created because the routines are used multiple times and it saved a lot of space in the wiring diagram to avoid unnecessary duplication (meaning: the diagram is going to be stretched to about twice its size on the screen - messy).

Thanks.

[Dennis_Knutson]

Your statements have me confused. What version of LabVIEW are you using? How did you create the exe that the installer would install VIs and an llb to anywhere, let alone the user.lib folder. You don't normally install VIs unless you are calling them dynamically.

[sjn]

<just back from Thanksgiving holiday>

1) Am using 8.5 in windows XP.

2) Created it the normal way (using the LabView help files as a guide) and all the pieces copied over normally - the stuff is IN the user.lib folder but the EXE would crash upon encountering one of those VIs (or the VI in the LLB).  THEN I tried cloning the entore user.lib folder from the source machine to the laptop and it didn't make a difference.

The problem is temporarily solved - I stretched my main VI all out of shape to directly code-in all the contents of the three VIs and now it works.  Unfortunately the current need and time allocation demands "make it work; it doesn't have to look pretty" ("exitus acta probat" ); hopefully I'll be able to revisit this one later and straighten-out the problem.

In the future, I'll be taking more notice of what's happening while I'm creating VIs with an eye toward this problem  - maybe I can figure it out that way.  The main VI that is the subject of this thread was written years ago and has been mutating and being patched through the years and software versions and has always run on a machine that had a full development package on it.

I thank everyone for their observations and comments.