Installed Program Error

[SBS]

I am having installation problems but not consistently. I have installed my LabVIEW-generated software using the exact same installer software on 5 separate non-LabVIEW PC's: four XP machines and one 2000 machine. The software installed without error and ran properly on 2 XP's and the one 2000. On the other two XP machines, it installed without error but when executed it gave me the error message: "The VI is not executable. The full development version of LabVIEW is required to fix the error."

Why would it install satisfactorily on some machines and not others with exactly the same operating system?

Side note: The computers with the two failed installations had their anti-virus/firewalls disabled or removed completely.

[tbd]

Hi SBS,

      Are there any ActiveX calls in the distributed App?

Cheers.

[SBS]

There are no Active X calls in my VI's. How can I determine whether NI's VI's have any? What would be the implication if there were?

[tbd]

Hi SBS,

      ActiveX calls invoke functions out of "type libraries" (DLLs) belonging to external appliactions and which can be different or missing from one machine to the next.  I don't think the "standard" LabVIEW VIs depend on any such external dependencies.  I'm not sure about add-ons like IMAX and other "exotics".

Speaking of external dependencies, does your code expect any special software or hardware be present?  Is the same NI-DAQ or DAQmx installed on all stations?

Another long-shot: Are you using call-by-name to run VIs out of a plug-in?

You're probably already considering: the fastest path to a solution might be to install LabVIEW on one of the problem stations - the License actually allows multiple (up to 3) installs, assuming only one user.

Cheers!

[gsussman]

I had a similar issue with a couple of XP machines.

The source of the problem had to do with the MS .NET framework not being installed on the problematic machines. Deep down in the code there was a single .NET call that caused the error. Installed .NET and the problems disappeared

A missing ActiveX control does not generated the error you are seeing.

[Jimmbo]

I agree. Most likely the .NET framework is not installed on the PCs where the application returns this error.  Just run Windows Update on the machines returning the error and install the .NET framework.

[tbd]

Hey SBS,

      Please share the answer when you find one.  gsussman probably has more experience with LV 8.x problems and I'd be interested if it is in fact the .NET issue.  When you said you used no ActiveX, it ruled-out that source of a problem, though Active X can cause broken VIs if, for instance, Excel is not installed on a platform, but the EXE expects it.  Mis-behaved Object Libraries won't "break" an EXE - the AX call simply won't work - but if the Source is opened on that station, then the source-code will be broken.

Cheers! 

Message Edited by tbd on 10-23-2008 03:00 PM

[SBS]

My app/installer will eventually be placed on a website and downloaded by "average" people, which rules out installing the "full" LabVIEW version and other well-intentioned suggestions.

Is there a way to determine what DLL's are needed and incorporate them into the installer?

Is there a better way to get version information? Most systems have a "tip strip" that displays this info when the cursor is placed on the "exe". Why not have a VI conveniently get the same information without specialized Active X controls?

Why do deficient app's build and subseqently install successfully and then simply refuse to run at all rather than producing an error when the Active X control is invoked within the app? Why doesn't the Application builder identify broken links, missing VI's, and required DLL's during the build process? It seems that having a successfully installed app display the message "The VI is not executable. The full version of LabVIEW is needed." is a rather cryptic error message late in the development process.

Thanks to all who contributed help and direction. Keep it coming.

[SBS]

My previous post was only the last part of the entire post for some reason. Here's the first part:

I believe I have located the source of the problem. After stating that I did not have any Active X controls, I discovered a "get properties" node in an "About" VI pop-up. When I removed the entire "About" the app installed and ran properly on the XP machines that had fatal errors before.

Now go to my previous post.

[tbd]

Hi SBS,

      While it's great that you've narrowed-down the problem, are you sure it's an AX node(?)  If you don't mind, please attach the About.vi.

> Is there a way to determine what DLL's are needed and incorporate them into the installer?

Any file - including DLLs - can be bundled with an installer, though, I don't know of any LabVIEW tool or function that lists all project dependencies such as DLLs.

You may not always want to bundle DLLs with your installer.  Some DLLs are installed with Windows Applications and may not work without other software components.

Re: Version info, as of LV8.5 (maybe earlier) there's an Application-class\Version property, though I'm not sure how useful it is.  Here's a good link on .NET methods for getting Version info.  In my opinion, NET is much friendlier than AX, though if these look like what you already have maybe gsussman nailed it after-all!

Yes, the EXEs error message is often (but not always) unhelpful.  Maybe LabVIEW could build/display a list of problems when one or more VIs in an EXE's hierarchy are broken(?)

More later!

---

SBS wrote:

My app/installer will eventually be placed on a website and downloaded by "average" people, which rules out installing the "full" LabVIEW version and other well-intentioned suggestions.

Is there a way to determine what DLL's are needed and incorporate them into the installer?

Is there a better way to get version information? Most systems have a "tip strip" that displays this info when the cursor is placed on the "exe". Why not have a VI conveniently get the same information without specialized Active X controls?

Why do deficient app's build and subseqently install successfully and then simply refuse to run at all rather than producing an error when the Active X control is invoked within the app? Why doesn't the Application builder identify broken links, missing VI's, and required DLL's during the build process? It seems that having a successfully installed app display the message "The VI is not executable. The full version of LabVIEW is needed." is a rather cryptic error message late in the development process.

Thanks to all who contributed help and direction. Keep it coming.

---