Relationships between EXE and Source Distribution

[_Y_]

Shortly: We desperately need a good hint on principles describing how an Application (EXE) build interacts with Source Distribution build(s). Descriptions found in ni.com and generally in Internet mostly advise “use Source Distribution” not saying “why”. It works perfectly with simple test projects but is not sufficient for our real needs. Please advice where the general principles can be read.

Details: There is a framework code (GOOP4 that means that all problems should be the same with build-in LVOOP). The framework dynamically invokes VIs. The dynamically invoked code also has OOP architecture.

A perfect architecture would be creating the framework EXE and keep the dynamically invoked code as loose VIs in HD. However, it does not work. The framework EXE claims that the VIs are broken (while they are not).

The common advice is deploying the VIs as a Source Distribution. However, this does not work too. If controlled with a property node “Execution state”, such a VI does not show the result “Bad” but an attempt to start it results in an error.

I guess that the problem could be in the fact that some classes are used both the framework (the EXE file) and in the Source Distribution. However, I have no idea how these two builds interact with each other deciding which copy should be used. Unfortunately, error numbers that are shown are poorly described. So far we could guess only that the problem is in finding some sub-VIs.

Thank you for reading to the end

[asbo]

If your end user does not have a development license for LabVIEW, they'll need an executable build in order to run your code (and even then you may have other runtime licenses to consider). There is no "interaction" between the two types of builds. At least in the old days, an EXE was just a source distribution which got wrapped in an executable and bootstrapped to use the runtime engine - not sure if it's as simple now.

Since you mention dynamically calling VIs, my guess is that you're not including all of the necessary VIs to run your code. You should probably post the errors you're getting in both scenarios to get more help.

[JamesMc86]

It does sound like you are missing some dependencies of your plugin VIs (this would have them report as broken). Using a source distribution for those VIs allows you to include all of their dependencies so you are sure that nothing is missing. I think packed project libraries could also be an alternative as they compile the code but I think people have had other issues with complex hierarchies in these.

[_Y_]

Thank you for the replies!

asbo, yes, the program is supposed to run-time license; yes, the plug-in VIs are not supposed to be incorporated in the EXE. I did not post the error codes intentionally. There was a variety of codes of very general scope. To my understanding, all pointed to missed linkage to sub-VI.

JamesMc86, yes, I believe some dependencies are missed (inly when called by EXE). However, the VIs are assembled in a Source Distribution.

Meanwhile I continue struggling with the issue using the great “guess-try-error” method. For some obscure reason I prefer “understand-create-enjoy” (actually this is why have I asked about basic principles). Anyhow the “guess-try-error” gave some result. Some plug-in VIs work if I include vi.lib in the Source Distribution. It is obviously a bad practice but any progress is better than none.

So I try to split my question:

1. What happens if the EXE and the dynamically linked Source Distribution contain copies of the same files and/or same classes? How the engine treats such redundancy?

2. If using Source Distribution is unavoidable, the reasonable way would be creating a separate Source Distribution build for each plug-in. However, this means enormous redundancy. How do multiple Source Distribution structures interact with each other if called by the same EXE?

[Ton Plomp]

Have you tried debugging your app? You can connect your LabVIEW instance to the build executable (even on a different machine) and try to get a better detail of the errors.

Ton

[_Y_]

Ton Plomp, I did not do such things in past. Could you write some details please? A link to RFM should also be fine

[Ton Plomp]

LMGTFY:

http://digital.ni.com/public.nsf/allkb/8DA679805915DE40862572D5007B2F70

Ton