12-05-2019 08:13 AM
Just thought I should share an observation about how dynamically loaded VIs (plugins) may fail to load their dependencies from within a built application, if the relative path to the executable has changed after the build - *if* the executable doe snot have an 8.x file structure (!).
Originally I had a project where plugins would be built as llb-files destined for a "PlugIn Archive". The Plugin archive folder would be located one level down from the location of the executable. Any dependencies that multiple plugins would share, would be included in the executable itself, so internally these plugins would expect to find their dependencies in "..\executablename.exe\dependency.vi". Now, if someone wanted to install a plugin after installing the executable, they were expected to do this by copying the plugin llb from the arhcive, to a folder in the executable's directory named Startup. This works, and part of the reason it works is that when these plugins are launched the relative path to their dependencies within the executable is still "..\executablename.exe\dependency.vi".
Now here comes the kicker; I wanted the plugin archive to be more organized, so I changed the build to put each llb in a subfolder of the plugin archive folder instead...so that any manuals or configuration files accompanying the plugins would be found nicely together with the llb file in that subfolder. This broke all the plugins that depended on something located in the executable which was not already loaded into memory by it at launch...
The reason for this is (well, as far as I know...) is that when "installed" by getting moved into the Startup-folder instead - they now expect their dependencies to be found *two* levels up - in "..\..\executablename.exe\dependency.vi". But the executable is just one level up from the startup-folder.
I had really expected the VIs to look for their dependencies within the executable, and be able to know where that was regardless of their relative location...but as this did not seem to be the case I tried to resolve this by adding VISearchPath-entries to the application ini-file....like <topvi>\* and the like, but to no avail.
Then I though about changing the file format of the application back to the old 8.x layout....and voila, the dynamically loaded VIs are now able to locate their dependencies - and they do so without any VISearchPaths required in the configuration file. The latter seems a bit strange though...should they not be able to locate their dependencies the same way regardless of the file layout...? The internal structure is less supportive of it yes, but it seems strange that an alternative support for such detection of available dependencies has not been added?
Anyway - I found a lot of discussions with similar issues here at ni.com, but they were all slightly different (the dependencies had not been included at all for example), so I am adding this here for others to see (and perhaps comment if there are more things to add, or I have misunderstood something about the issue...).
12-05-2019 08:27 AM
Come to think of it I did a similar change on an application built for Linux RT, and it did not have the same troublesome effect there - even though the format was not set to use the 8.x layout.
Perhaps this behavior is limited to Windows 🤔