"Spherical Bessel Function jn.vi" not found in built app

[NathanT]

MattI,
      To answer your first question, I think the breakdown in communication is caused by the forum's efforts to get your application to work on a deployment machine, which was the original purpose of the thread, correct?  The issue with the placement of the .dll or fake .dll causing errors is not in keeping with the original thread title and purpose.  First and foremost, we want you to be able to move on with the development of your application, in which you will be deploying to machines that do not have the development environment.  If you create an installer with the correct support, OR use the full version of the RTE, you should not have to worry about moving around the lvanlys.dll, and be able to continue developing your application.

A couple of things for you:

Please attach the error message. 

Does this behavior only occur on a machine without the development environment, and without NI-DAQ, but with the full RTE? 

Does this behavior keep you from developing your application?

Thanks,

NathanT

[MattI]

I've tried to upload the err msg again (don't know why it didn't happen on my last post).

My concern with built apps not working unless certain unneeded files are NOT present is that I can't always control what file users (including files added by other developers) might add.

It would be one thing if the error message said something like, "Sorry, dll found in an unwanted location".  Instead, you get an error message that doesn't really give you any insight the failure mechanism.

To answer your question "Does this behavior keep you from developing your application?", I have never had a problem building the app.  It has been and continues to be the same problem, that the built app reports that the Bessel function is not found.  I am merely diagnosing the problem / behavior / dependencies further for NI's benefit &, hopefully, an (eventual) root cause fix.

To restate one point on my last post in more detail, I grabbed a PC & wiped it clean w/ WinXP, and then installed LabVIEW 7.1 runtime engine from your website, and still see the same behavior as I've described elsewhere in the thread.

So, to answer your question "Does this behavior only occur on a machine without the development environment, and without NI-DAQ, but with the full RTE?", the answer is yes, but only if lvanlys.dll is present in the same dir as the executable (aka "built app").

As another point of information, I've discovered that the only place where lvanlys.dll is needed is:

C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\7.1

If I remove lvanlys.dll from that location, then running my built app results in the RunTime Engine installer coming up, because it wants to create this file.  It's interesting that if I cancel the install, then it asks me to browse for where lvanlys.dll is, and if I take it to a directory that has it, then it's happy.  In fact, if I put lvanlys.dll into the .exe's directory or a subdir, it finds it on its own & loads up after a very short additional delay.

That seems logical.  But it does imply that building the app doesn't need to bring along the .dll file to anywhere on the target PC, so I don't know why NI App Builder even bothers to include it in the build, since it already exists in the above directory (presumably from the runtime engine installation; after all, when I blew it away & then ran "repair" with the RTE installer, it put it back), and it obviously knows to look for it there.

OK, now for the wierd news.  After going thru the above mentioned experiment, I can no longer replicate the problem.  No matter where I put lvanlys.dll, it doesn't mind any more.unneeded

[NathanT]

Good Morning Matt,
      I just ran some tests on a clean XP machine with the LabVIEW 7.1 Run-Time Engine from NI.com installed, NI-DAQ was NOT installed.  The executable that I used just had "Spherical Bessel Function", two controlls and one indicator.

With just the LV 7.1 RTE, the executable ran fine
When I added a good copy of lvanlys.dll to the exe folder, it ran fine
When I renamed lvanlys.dll in C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\7.1, it ran the installer, and when I canceled the installer, I could browse to the renamed dll, it then ran fine
In the same case of renaming the dll in C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\7.1, but with a good copy of the dll in the exe folder, it also ran the installer, but did not prompt to browse after cancelling the installer

When I put a bogus lvanlys.dll in the exe folder, I got the "Bad Image" error code that you attached to your last post.

So it seems that in order to cause a problem, the user has either

1. Delete or rename a necessary dll from C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\7.1

OR

2. Put a bogus dll in the same directory as the executable

I did not encounter any problems when putting a good copy of the dll in the executable directory.


"so I don't know why NI App Builder even bothers to include it in the build"  Which instance are you referencing to?  I just created a simple executable and it ran fine.  When creating an installer, the different "Advanced" options determine what parts of the RTE are included in the installer.  I cannot see a case where one of the LabVIEW dlls would need to be the the same folder as the executable.

Please let me know if I did not include a common case in my testing.  I want to make sure that we are on the same page.  Thanks for bringing this issue to our attention.

Cheers,

NathanT

[Travis_M.]

Hello Nathan and Matt,

Just to recap what is happening -- the anlysis dll is used by the Bessel function.  The runtime engine installs this DLL in all versions of LabVIEW (at least since 7.0) when you select to include the analysis support in the runtime engine installer you create.  When the LabVIEW 7.1 EXE loads, it first attempts to load the dll from the top-level folder (where the exe resides), and then from the runtime engine location.  I agree that this creates a problem since users have to know better than to put a dll with the same name in the top-level folder or they could get an error.  I was all ready to file a bug report for you, but I discovered that this has been changed in 8.2 (probably in 8.0 as well).  Now, you create you exe, the analysis dll is automatically included as a support file in the /data directory.  The EXE first tries to load the DLL from this folder, then the runtime engine, then the top level.  So in this case, the user would never see an error by adding a bad dll to the application folder.  In your set up installing DAQ added the runtime engine which resulted in creating the analysis dll in the appropriate runtime engine folder.

I do hope that this helps clear things up Matt – please don’t hesitate to let us know if you have questions.  I, an AE, or someone in the LabVIEW community should be happy to help.  Have a great afternoon-

[bfarley]

OK, I'm having kind-of the same problem and I'm not sure I get what exactly I'm supposed to do about it.

I compile an app that requires the lvanalys.dll in LV8.0.1.  The \data directory is created and the lvanalys.dll file is put in there.  If I run the executable on a machine that ONLY has the 8.0.1 runtime installed (LVRunTimeEng801.exe downloaded from NI), I get an error that says - lvanalys.dll is not a valid LabVIEW file, followed by a bunch more errors about missing vis.  If I run the executable on a machine that has LV installed, it runs fine.

There were words about including analysis support when the runtime is installed, but I don't get any options like that when the runtime is installed or if creating an installer.

TIA,

Bill F

[NathanT]

Good Afternoon Bill,
       What other VIs does the error code say that it is missing?  Can you attach your executable for me to test and try and reproduce the behavior?  What is the overall purpose of your application?

Thanks,

NathanT

[bfarley]

Nathan,

I figured out my problem.  I downloaded the wrong runtime.  I was using the one for remote panel viewing instead of the full up version - Doh!

Bill F