My program runs fine within the LabVIEW development environment but produces error 1003 when run as a standalone executable

[DavidFCannock]

I'm working with LabVIEW 2015 (32-bit) and I'm trying to produce a working executable distribution of one of my applications. The issue I'm experiencing is that my application runs fine within the LabVIEW development environment but encounters a problem when I produce a standalone executable (Application (EXE) build) of it and run that. My project layout is shown below.



My project contains three sublibraries: "Application Launcher.lvlib", "Application.lvlib" and "Utility.lvlib". The top-level VI is situated in "Application Launcher.lvlib" and dynamically launches "Run Application.vi" within "Application.vi" in call-and-forget mode. The code for "Launch.vi" below is a little messy since I've been trying to play around with a few things.

Initially I suspected that it was an issue of providing the correct path to "Open VI Reference.vi" in the standalone executable case. However, I found out that "Run Application.vi" was being launched successfully in both cases. The issue is being caused by the fact that the main body of my project is contained within "Application.lvclass" which is a type of actor, and when I try to launch it within the .exe's version of "Run Application.vi", I get an error complaining about VIs not being executable (error 1003). The code for "Run Application.vi" is given below.

When I run my application as a standalone executable, the following error dialog appears:

My standalone .exe build is configured to include all source files. LabVIEW 8.x file layout is disabled. Nothing is checked under "Additional exclusions". Project dependencies and all source files are configured to be contained within "AGTS.exe".

[Sam_Sharp]

In the screenshot you posted - the type definition is greyed out which means it isn't up to date.

Unless it's something completely different/unrelated...

It looks like you're making pretty extensive use of packed project libraries - you need to be very careful about namespacing and where dependencies are located in the packed project libraries. If you have a type definition that is used between libraries and you need to transfer data between them, myControl.ctl in PPL1.lvlibp is not the same as myControl.ctl in PPL2.lvlibp. You will get a lot of run-time errors about incorrect type definitions.

I suspect that might be the issue here - you need to take any shared dependencies and put them into another PPL and then make sure each module uses the version of the dependency from the PPL.

[DavidFCannock]

---

@Sam_Sharp wrote:

In the screenshot you posted - the type definition is greyed out which means it isn't up to date.

Unless it's something completely different/unrelated...

It looks like you're making pretty extensive use of packed project libraries - you need to be very careful about namespacing and where dependencies are located in the packed project libraries. If you have a type definition that is used between libraries and you need to transfer data between them, myControl.ctl in PPL1.lvlibp is not the same as myControl.ctl in PPL2.lvlibp. You will get a lot of run-time errors about incorrect type definitions.

I suspect that might be the issue here - you need to take any shared dependencies and put them into another PPL and then make sure each module uses the version of the dependency from the PPL.

---

> In the screenshot you posted - the type definition is greyed out which means it isn't up to date.

No that's just an issue with LabVIEW's VI Snippet functionality. You should see how badly it messes up OOP code. It's fine in the code itself. The type definition in that image is part of the same class as that VI is a member of.

> It looks like you're making pretty extensive use of packed project libraries - you need to be very careful about namespacing and where dependencies are located in the packed project libraries. If you have a type definition that is used between libraries and you need to transfer data between them, myControl.ctl in PPL1.lvlibp is not the same as myControl.ctl in PPL2.lvlibp. You will get a lot of run-time errors about incorrect type definitions.

If this were the issue, wouldn't it prevent my application from running properly in the LabVIEW IDE as well as when it's a standalone application?

[Sam_Sharp]

---

DavidFCannock wrote:

If this were the issue, wouldn't it prevent my application from running properly in the LabVIEW IDE as well as when it's a standalone application?

---

I'm not sure - the PPLs obviously are fine otherwise you wouldn't be able to compile them if they were broken so I think your problem is to do with the relationship between the PPLs and your application - when you build the executable, the paths change (everything inside the executable becomes Application.exe) so if a PPL calls another PPL, it has to be able to find it in the place it expects.

I thought I knew a fair amount about PPLs but I still consider them to be a bit of a dark art!!

[DavidFCannock]

---

@Sam_Sharp wrote:

---

DavidFCannock wrote:

If this were the issue, wouldn't it prevent my application from running properly in the LabVIEW IDE as well as when it's a standalone application?

---

I'm not sure - the PPLs obviously are fine otherwise you wouldn't be able to compile them if they were broken so I think your problem is to do with the relationship between the PPLs and your application - when you build the executable, the paths change (everything inside the executable becomes Application.exe) so if a PPL calls another PPL, it has to be able to find it in the place it expects.

I thought I knew a fair amount about PPLs but I still consider them to be a bit of a dark art!!

---

PPLs can't be included inside the built executable, so LabVIEW moves them to a support directory in the build output folder that's called "data" by default. I had a working version of the standalone executable before but that was with much older versions of these PPLs. This is what my output directory structure looks like:

The packed project libraries are all contained within the same folder as each other just as was the case with "<Project Root>\lib", so their relative paths to each other was the same.

I'm exploring different project redistribution options with NI's help (http://forums.ni.com/t5/LabVIEW/How-should-I-make-my-projects-redistributable/m-p/3215262) so I might end up moving away from packed project libraries in any case.

[K-Derrick]

I had the same issue using packed library (built an OOP packed library plugin) and creating an executable in LabVIEW 2013. After painful two days of troubleshooting, I found what may have caused the problem for me at least. The final solution was to re-create a new build specification for the executable.

After building a working executable from a new build specification within the same project, I compared the build specification of the old with the new within the .lvproj file (in XML format) and notice a property name “Destination [0].preserveHierarchy”. New build was set to true and old was not included. This feature is grayed out in the Destination section under Destination type of the Build Specifications. This may have cause the error of not finding the library hierarchy or path correctly.

Now I will be re-creating new build specification every time I include new features like packed libraries.