The VI is not executable. The full development version...

[iannicholson]

"The VI is not executable. The full development version of LabVIEW is required to fix the errors." That is the error I've been dealing with all day. Actually it is repeated 3 to 4 times in the error message, seen when first launching the EXE. Also of note is that the run-arrow is broken. This is in an EXE that was developed well before version 2013, but I recently upgraded it to 2013 to hopefully fix some random LVRT crashes. There is obviously no issue running the code on my development machine, only once it's deployed.

The good news is I've been able to solve the problem (mostly). My EXE now runs without the errors. I found that the problem wasn't actually in the EXE.

We have a separate project with no files, but in the build specification we have the LabVIEW 2013 Run-Time Engine, as well as NI-VISA for serial support. We then bundle the deployment in a self-extracting RAR and it does its business. In the past this has worked just fine, but with LV2013, it seems that there is a component missing from the deployment.

I found that if I download the Run-Time Engine directly from NI.com and run it, the only things I need to install are the Run-Time Engine, and the DEPLOYABLE LICENSE. If I do this, my EXE runs great, but with the custom installer, it is not included for some reason!

Putting aside the fact that I don't know why the Deployable License package is needed (we aren't connecting to remote panels), I can't seem to modify my custom installer to install the Deployable License. There are versions for LabVIEW 2009 and 2011 SP1 in the Additional Installers list, but I don't see 2013.

Can anyone explain why this is??? For now I will just distribute the 257MB Run-Time Engine and the NI-VISA installers separately I guess. But I'd really like to get back to a single, simple package to install all the prerequisites we need. HELP!

[James-K]

Hi,

Why do you build the installer from a project with no files rather than from the project including the VI?  I would recommend trying to build an installer from the project that actually contains the exe you want to distribute.  

[iannicholson]

Yes, but then every installer I build will contain the runtime engine. That gets very large very quick. So I have an installer for JUST the runtime engine and VISA runtime.

[crossrulz]

---

@iannicholson wrote:
Yes, but then every installer I build will contain the runtime engine. That gets very large very quick. So I have an installer for JUST the runtime engine and VISA runtime.

---

Just remove them from the "Additional Installers" tab of the Installer dialog.

[iannicholson]

What I'm trying to accomplish is to build an installer which will contain the two runtime engines, so they don't have to be installed separately, and they don't need to be packaged with the EXE I build. This has worked fine in previous versions, but it breaks the EXE in 2013.

[DougFerguson]

I am having this EXACT problem today on 2012. The executable is an old one that has been archived for sometime and runs on other machines just fine. The only thing I have recently created was the installer. What gives??????

[prenaut41]

I am having a very similar problem with LV 2012SP1, although I don't know if it is necessarily related in causality. 

I have an application that was running fine.  I then added some additional functionality and now the new application builds will not run from the .exe file (although they work fine in the development system). 

I receive two "LabVIEW Generic File I/O Error" messages.  One that states "SetDDTAttributes.lvlib' could not be loaded and another that states 'GetSetShared.lvlib' could not be loaded.

The I get the message "The VI is not executable: The full development version of LabVIEW is required to fix the errors." 

Both of the above lvlib are listed in the dependencies for this project.  I think they are related to some functionality I added to in sub-VIs to programatically name plots on a chart, get and set y-axis ranges on a chart, or something along those lines. 

Any suggestions on how I could fix this?  Is the full develpment version really required?   

Thanks for any help,

Paul

[prenaut41]

Looks like I solved the problem, although it seems kind of silly. 

First of all, I realized that the problem only occured when I tried to run the .exe application on the development machine.  When I built an installer and put that on a target machine, the program ran just fine. 

On the development machine, it seemed I was able to get the application to run fine just by changing the application file name when building the application.  I had been using a file name with some text name, an "_" character, and followed by a date tag of 20131130.  When I truncated that name such that I dropped the "_20131130", everything was fine.  I didn't play around with more versions of the file name, so I'm not certain if it is the "_" character or just the total length that was causing a problem. 

The curious thing is why this would cause the error messages I received related to the 'SetDDTattributes.lvlib' and 'GetSetShared.lvlib' and the message that the full development version was required to fix the errors.  Oh well. 

[ChazMasterFlash]

After a bunch of screwing around I was able to solve my instance of this problem: It was related to how I created the reference controls within an asynchronously called VI.

I tried everything, as I see lots of users have on these compiler error posts.  I did the whole mass compile, the .NET framework upgrade, etc, etc...

My "conjecture" is that LabView does not handle references as rigourously as most computer languages. You need to be very careful when compiling these, esp if you have local variables of reference controls. I know that this technically is not correct programming etiquette, but you need to close references and the easiest way is to use local variables to references.

Gawd I wish NI gave us more direct use of pointers (which is essentially what a reference is). If I had direct access to address of a variable, I think troubleshooting would be made much easier.

Am I alone here?

[Candan]

For the same error message, our customer has solved the problem by manually installing .NET v3.5. Here are the computer details:

Development PC Details: Windows 7 x86, LabVIEW 2012

Deployment PC Details: Windows XP x86,  LV Run-Time 12.0.0 (and 12.0.1)

As mentioned in the thread, possible reason for getting this error might be related with usage of the local variables (copies) of the references.