Dependencies in VIs called by 'Start Asynchronous Call' and best practices

[Les__Bartel]

My application uses 'Start Asynchronous Call' to launch VIs one at a time for a test. Main can communicate with these VIs via a queue that is passed in to the VI. After deploying my application, I would like the ability to add additional VIs for additional tests (without deploying the entire app). These VIs share subvis in main as well as require their own subvis. Some of the dependencies make sense to be in the executable even though they aren't used in the exe and others belong only to the test VI. For some of the VIs that I launch, the 'Searching for vi' dialog pops up and disappears very quickly and the vi doesn't run. The error message from 'Start Asynchronous Call' indicates that the VI is broken. I'm quite sure that it can't find all of the dependencies. I have two questions:

1) How can I quickly find those dependencies?

2) What is considered the best practice for ensuring those dependencies can be resolved in my deployed app?

Windows 7, LV2017

[Kyle97330]

I'm assuming you're loading these by the path on disk now?

Switch to using a static VI reference from the Application Control palette.  Right-click it and choose "browse for path" to select the VI.  Then right-click again and enable the "Strictly typed VI Reference" option.  Then, use a property node to get the VI path for the "Open VI reference" function and wire the reference into the type specifier along with whatever options you need to use to prepare it to launch asynchronously.

The static VI reference loads the VI into memory along with all its dependencies as well as insuring it and its dependencies are built into an EXE.

Edit: Oops, I now see that you want to add new VIs later.  I don't think that's really a thing you can do from an EXE.  You probably will have to just recompile the EXE each time.  The only thing I can think is that maybe if all of your VIs you want to test have the exact same connection pane, maybe you could compile them into a DLL that you load dynamically and then use a library node to call them by reference? You'd still have to build each new VI as a DLL...

[aputman]

I'm sure someone will correct me if I am wrong but I don't think a plugin VI (outside of the EXE) can call a subVI that is compiled into the EXE. Is that what you are trying to do?

[crossrulz]

I think a Packed Project Library is the closest to what you want.  Any shared dependencies between the EXE and PPLs should be in it's own PPL.

[paul_cardinale]

---

@aputman wrote:

I'm sure someone will correct me if I am wrong but I don't think a plugin VI (outside of the EXE) can call a subVI that is compiled into the EXE. Is that what you are trying to do?

---

I think that it can, as long as the VI is loaded into memory.  However if some subVIs are included in the .exe, but not referenced in the main code, they may not be loaded.

Les__Bartel : Try including in your Main VI, static references to all subVIs that it doesn't use.  That will force those subVIs to be loaded, and should make them available to dynamically loaded VIs.

[this_one_time_at_vancamp]

Les__Bartel, it looks like several potential solutions have been provided above. Did any of these work properly for you? If you have found a solution, feel free to mark one of the responses as correct to give us some feedback on your status. This way, other people with similar questions will more quickly identify solutions, and those who provided the solutions can receive credit for their work.

MVC

[Les__Bartel]

---

@this_one_time_at_vancamp wrote:

Les__Bartel, it looks like several potential solutions have been provided above. Did any of these work properly for you? If you have found a solution, feel free to mark one of the responses as correct to give us some feedback on your status. This way, other people with similar questions will more quickly identify solutions, and those who provided the solutions can receive credit for their work.

MVC

---

There are 3 workable solutions. The first one doesn't work for me, and the author edited his post to admit that. It could work for others. The packed project library looks like it would work for me, but as I was looking into it, it seemed pretty complicated and I haven't taken the time to understand and implement it. At this point I'm going with the 3rd option. All 3 deserve credit for providing useful answers.