Please help suggestions for solving built-only compiler error: 'The VI is not executable. The full development version of LabView is required tofix this error.'

[ChrisBaten]

We have develoepd a software tool and build it on regular basis. It currently runs error free when compiled in the editor, but when we built it and run the executable stand alone we get the error.

'The VI is not executable. The full development version of LabView is required tofix this error.' plus a broeken error.

This menas an compiler error that is not present in the editor but in the stand alone version. We tried to identify errors as suggested in several posts in this forum, but so far unsuccesfull.

As the editor and its compiler do not see the error  and are running fine and the stand alone version just syas 'find the error in the editor' in this case LabView is of no help.

Can anyone suggest a sensible or 'good practice ' way of searching for the source of this error?

Our project  comprises hundreds of Vis over several libraries.

Thanks,

Chris

[GerdW]

Hi Chris,

sometimes such errors have their origin in some (conditional) disable structures. When switching the case of such a structure to the "Runtime Engine" case you might activate some broken subVIs...

[ChrisBaten]

Thanks Gerd,

You are correct, and yes we use those, allthough never for not working parts of software.

Currently I am working along the lines of disabling parts of the project and rebuild in a kind of splitt search approach.

I will doublecheck our conditional disables including spellchecks in my next round of building (takes 15 minutes or so. 😞 ).

Switching them to 'false' is the eassiest way of disabling parts, calkling different com objects, of the project anyway.

I am afraid it is related to something like the 'this vi' reference folder name, which is different for compilation in the editor and compilation in the builder. Allthough we ealt with that by checking on '.exe' or '.dll' long time ago.

Chris

[Craig_]

Have you tried enabling debugging in the build?

If its still broken you can connect to the exe with LabVIEW and look around for what may be causing it. Keep an eye out for broken subVIs and for save prompts when you disconnect from the session.

Are you using many classes? Have you verified that the proper access scopes are set for functions calling those VIs?

Does the exe run on your development machine? Sometimes if the code uses .net assemblies deployment machines which do not have the correct .net framework installed get this error.

Hopefully this provides some tips!

[ChrisBaten]

Thanks Craig for all your suggestions.

We seem to have located the problem in a new vi just added to the package causing conflicts by using the same vi names as other vis already present in the package. Excluding this vi removed the error.

It seems related to a conflict by having two vis with the same name, which was mentioned by LabView and interactively resolved when running the main vi from the editor. When successfully building the main vi the builder did not mention this conflict and reported a successful build, but when trying to run the executable it gave the cryptic error. The error caused us problems because there was no hint for the cause, just the suggestion to solve this in the editor, while at the same time in the editor the VI was running fine.

We will post about this in detail after we have positively proven that this actually was the case.

The .net version issue was already checked.

Performance was the same on all machines we tested on including the dev machine.

Debugging was tried nut did not help as the vi could not run (broken arrow). We assumed that debugging only helps in running faulty functioning vi''s. We did not check for broken arrows in sub-vis (after connecting), that could have helped, although our application has hundreds of our own vis.

In relation to your remark: 

'Are you using many classes? Have you verified that the proper access scopes are set for functions calling those vis?'

Could you elaborate on setting access scopes. We were not aware of this option in LabView, although we realize this is a basic element of the underlying c code.

Ragrds,

Chris

[Sam_Sharp]

I have had the same problem before and it was because I was trying to install the software on a PC running Windows XP which did not have the .NET runtime installed.

My application used .NET calls (the lovely NotifyIcon library) and some of the PCs were old, running Windows XP and were missing the .NET runtime. After that was installed, the error went away.

(I've just realised that you've implied that you're running on the same PC as you built the executable with - I'm posting anyway as it may help others searching for the same problem)

[ChrisBaten]

Thanks, yes we tested also on the dev pc, but this can occur easily when distributing over other pcs without clear error reporting..

Is this actually checked by the labview installer if you make an installer package for it? Or can you set the installer package builder to do so? By e.g. requiring an newer windows version in the tab: adavanced-system requirements in the assumption that this ensures a certain vesion of .net framework being installed?

Chris

[JosD]

Hi,

Here you will find some instructions how to include the .NET framework in your installer package:

http://digital.ni.com/public.nsf/allkb/51698977FC8DA9E48625760E00689C5E

Also this site might be of some support:

http://digital.ni.com/public.nsf/allkb/F715F1ED66878F8E862574F8006AD6A1?OpenDocument

As fas as I know, the LV installer does check for the presence of .NET if it is needed, but the returned error code may not be clear enough. Hopefully these links help out...

Kind regards,

Jos Deurloo

National Instruments

Applications Engineer