LabVIEW:EXE generates error 1003 calling plugin with type definition

[LabVU_Dog]

Hello all,

I'm running LV 2012 on a Win 7 machine. I had this same problem with LV 2011, so I feel sure it is not version/upgrade related.

From a LV-built EXE, I am attempting to call a dynamically loaded subVI. I have done this many times successfully before, so I think that I know how. I prefer to use the Call by Reference, but I get the 1003 error at Open VI Ref (with type specifier). If I don't use the type specifier, I can open the subVI, but the state is listed as "Bad." I then went recursively through all the subVIs (~25 total), and found that the only item with a "Bad" state was a type definition.

I have verified several times, several different ways, that all the subVIs (and the "bad" Type definition) are available to the dynamic subVI. I made sure the type def is correct. I have also made sure that the subVIs are stored as .VI files in the same directory, and not inside an EXE. When I attempt to execute the Run VI invoke node, I still get the 1003 error. I have verified that the path that shows in the error dialog is the exact path to the subVI (it would have to be for the other VI properties and methods to work correctly). 

Why am I unable to execute a dynamically loaded subVI from an executable if it has a type definition (a cluster of 3 paths) as an output parameter?

[LabVU_Dog]

There is more to the situation.

I was just able to successfully test a simplified case. I built 1 EXE where I included the dynamic subVI (from a different project) in the build. I set the destination to be the same directory as the EXE, but not inside the EXE. All of the subVIs for the dynamic subVI were contained in the EXE. When the EXE executed, it was able to load the dynamic subVI and run correctly.

I then tried another variation. I put all the subVIs for the dynamic subVI in the directory, not inside the EXE. All the subVIs are contained in a single project library. The EXE also uses some subVIs from the same project library. This variation also executed correctly.

I should note that in both cases, I used the Call by Reference node. I tried using properties to set the control values and then using the Run VI invoke node, but was not successful. I did not troubleshoot that avenue further, probably its a problem on my side.

It seems a more complete description of my problem may be in order. I will include that in the next post.

[LabVU_Dog]

My full situation contains 2 projects, A and B, each with an executable. Both projects have only 1 top-level VI.

Project A is a small project designed to create a flexible EXE that can be called for execution upon completion of installation (using LV-created installer) of B. The executable files (.EXE, .INI and .ALIASES) for A should never need to change. I plan to put all the project-specific stuff (for B) into a single subVI (called dynamically by A after the end of installation of B) and an INI file. These two files, a dynamic subVI and INI text file, will contain all the project-specific information.

Project B is the real application. It needs to perform tasks that require admin privileges, such as write registry settings and set file/directory permissions. Previously, it had been acceptable to require the user to run the executable with admin privileges the first time. As the scope of the project has greatly increased, this is no longer an option. The new requirement is to write the registry settings, create the directories needed, copy files, and set privileges during installation.

So I have built A into an executable, and left it on my hard drive. In project B, I have an EXE build script and an installer build script. I include the 3 executable files from A (.EXE, .INI and .ALIASES) as support files in project B. The dynamic subVI (to be called dynamically by A at time of installation of B) is statically linked to the top-level VI in B. I use a project library that is shared by both projects. Both top-level VIs and the dynamic subVI are statically linked to one or more subVIs in the project library.

In the EXE build script for B, I set the properties for the dynamic subVI to set the destination in the same dir as the EXE (so that executable A can call it dynamically), not inside the EXE. I also set the destination for all components of the project library to be in the same directory, not inside the EXE.

I suspect that my problem may have to do with the fact that when A attempts to load the dynamic subVI, there is some complication due to the fact that the dynamic subVI (and all his subVIs) were created as part of the B build. The top-level VI for A contains other components of the project library that is shared between applications A and B. Note that the EXE build scripts for both include "Remove unused members of project libraries" and "Modify project library after removing unused members" as checked.

Perhaps the built version of that project library for A is smaller/different than for B, and A doesn't know how to handle that in a dynamic subVI?

[LabVU_Dog · Accepted solution]

I just tested an idea: renaming the project library in project A build script. Now when it loads, it doesn't confuse what it needs internally with the externally called (dynamic) subVI. It worked on the first try!