Can't launch the compiled EXE from the development machine (The VI is not executable...)

[Nienscecco]

Bonjour,

I use Labview 2015 32-bit on a 64-bit Win& pro computer.  My application connects to Hardware using NI-VISA and NI-DAQmx only (Two RS232 communications via a VCOM port and one NI DIO card using DAQmx).  

Until today, I was building an executable which  I was copying through the network on another win7 pro machine in the lab next to the hardware.  It was working fine with Labview Runtime 2015 installed on this machine along with NI-VISA and NI-DAQmx.  I never used an installer, I installed those 3 components seperatly.

Yesterday I added some features to the application and the EXE won't start.  I have an error msg saying "The VI is not executable. The full version of Labview is needed to fix errors".  The machine in the lab can't run the EXE but the EXE won't even start on my development machine.  

• My previous EXE from last week still works fine.
• The code works fine with all new features if I run the main VI from the development environment.
• I've double check all of my licences status.
• If I open another project and compile the EXE, I am able to run this EXE (I use a complex app containing almost all the same software components)
• If I build an EXE with a different UI source file part of the same project, that EXE works fine.
• If I build the EXE from my previous version again, it works fine too.
• I tried removing all the new features I had added in the project and build the EXE again and I still get the error.
• I tried creating a new project file and import the same librairies to try building an EXE from a fresh project file and I still get the error.
• I tried installing Labview 2015 on another computer and try to build an exe from a fresh labview install on this computer and I get the same error. The development machine can't execute the compiled EXE)

It has to be related to the code but, I can't roll-back and get functionality of the EXE again unless I totally replace all of my files from a backup made last month.  The most recent posts I read from a similar error are from 2013 and later.  And the problem described is always that the EXE does not work on the deployment machine but works fine on the development machine.  I must be at version 25 of this application to which I add improvements on a regular basis since almost 1 year.   I am really puzzled.  Is there a way to analyse or get more info about the broken EXE error?  All the new features I added are using components that were already present in the project and in the main VI.  The new features are important, I'd really like to use this working code with the hardware as soon as possible but I don't really want to install labview on the development machine.

Any ideas? I don't know what to try next.  What would be the best information to provide / look for for the next step?

Thanks to all in advance
Nien

[smithd]

6 hours ago, Nienscecco said:

Any ideas?

Please please please start using source control other than a monthly backup. Go to https://www.sourcetreeapp.com/, install it, and create a new repo "add" a working copy option. Everything is embedded, no separate server is necessary, you're just comitting changes locally. Its 5-10 minutes to set up, then all you have to remember to do is to commit occasionally -- I do it like every hour, some people prefer when they finish a feature, but in any case its easy and simple and would solve this problem in the future.

 

OK, so now to try to fix the issue. My first thought is to try to enable debugging in the exe, and then connect your labview debugger to it. This may not work since its broken from the start, but is worth a try:
http://zone.ni.com/reference/en-XX/help/371361N-01/lvhowto/debug_apps_dlls/
http://digital.ni.com/public.nsf/allkb/8DA679805915DE40862572D5007B2F70

If that fails, on the "additional exclusions" tab of a build spec there is a series of checkboxes. These would be better labelled as "toggle randomly to fix build" rather than the existing names. As mentioned, please toggle them randomly and see if it fixes the build. On the advanced tab, there is an option for using 8.x file layout. Same basic idea.

[Nienscecco]

Thank you for your suggestions.  I will try that.  

I totally agree with you on the source control part.  I just arrived (more than one year, but believe me things are moving slow when you work for the governement...) in a government agency research group...  The persone before me has been doing things on his own for 20 years without source control and no real backup solutions. To implement a source control solution here is a huge quest.  To have access to a server or even get admin rights to a machine which is connected to the network is a contract I need to sign with my own blood (when there is a possibility at all).  I am familiar with Tortoise/SVN but I've never setup a server myself.  I will visit the link you posted.  Let's just hope I would be able to have the permission to install it on my development machine.

Again, thanks for your suggestions.  I may have to wait until 2 days before I can try that thouhg.  My work priorities are changing quickly here. :O) 

[Nienscecco]

If that fails, on the "additional exclusions" tab of a build spec there is a series of checkboxes. These would be better labelled as "toggle randomly to fix build" rather than the existing names. As mentioned, please toggle them randomly and see if it fixes the build. On the advanced tab, there is an option for using 8.x file layout. Same basic idea.

Smithd, you are my new Hero! Your insights were right on!

As expected, debugging the EXE did not work because it was broken right from the start.  The connection was occuring though but the exe only showed a broken arrow (That is usually hidden when my application runs normally) and nothing happened if I clicked on it. But still I was having a disconnection warning when closing the broken EXE...

The solution came with your second suggestion.  Adding a checkmark to "Disconnect type definitions" from the Additional Exclusions tab fixed the build.  It makes sense to me because I remember I accidently saved a typedef double during my most recent modifications. I thought I had corrected myself and deleted the double from the disk and from the project but obviously something slipped through my fngers.

I spent the rest of my day learning about Git, GitHub and SourceTree.  I will probably stick to Subversion though.  It's well overdue that I finally implement a source control solution in here!

Problem solved.  Thanks again!!

[smithd]

2 hours ago, Nienscecco said:

I spent the rest of my day learning about Git, GitHub and SourceTree.  I will probably stick to Subversion though.  It's well overdue that I finally implement a source control solution in here!

Problem solved.  Thanks again!!

Glad that worked. And yeah, the sourcetree/git was only because its available even from a single machine without setting up a server. The other differences between git and svn aren't sufficient to get worked up over.

[JKSH]

3 hours ago, Nienscecco said:

Adding a checkmark to "Disconnect type definitions" from the Additional Exclusions tab fixed the build.  It makes sense to me because I remember I accidently saved a typedef double during my most recent modifications. I thought I had corrected myself and deleted the double from the disk and from the project but obviously something slipped through my fngers.

Have a skim through this thread, which discusses some of the quirks of type definition disconnection: https://forums.ni.com/t5/LabVIEW/Application-Builder-What-does-quot-disconnect-type-definitions/td-p/2992511