12-12-2025 04:27 AM
In ye olden days you could list files in an .exe and find them, but since many years now you cannot, so what's the best way to find them? They're not listed in the ExportedVI-list?
Solved! Go to Solution.
12-12-2025 08:53 AM
It depends on what you really need. If you just want to get a list of the loaded VIs inside of executable, you can use the *All VIs Paths in Memory* Property Node. However, if you need to "disassemble" the executable (without source) into separate SubVIs, you can use pylabview (some Python knowledge is required).
12-12-2025 10:37 AM
@Andrey_Dmitriev wrote:
It depends on what you really need. If you just want to get a list of the loaded VIs inside of executable, you can use the *All VIs Paths in Memory* Property Node. However, if you need to "disassemble" the executable (without source) into separate SubVIs, you can use pylabview (some Python knowledge is required).
That's just the problem, if you include a class in Always included, it doesn't list with that node until you've done a Open VI, which i'm (or rather a collegue) is missing the path to.
12-14-2025 02:56 AM
LV maintains the relative paths inside the EXE (with vi.lib stuff going in a 1abvi3w folder). The exact structure of an EXE is a bit more complicated, but you can see this behavior if you look at the build folder while the build is happening (although that might end up messing your build up).
The practical upshot of this is that if you want to include something in the EXE without loading it statically and then load it, you can simply place a VI in a known relative location (for instance, in the same folder or a parent folder) and use the path of that VI to get your final path. That VI can be called statically and the behavior should be the same in LV and in the EXE, as the paths of items included in the EXE are stored relatively.
12-15-2025 03:22 AM
@tst wrote:
LV maintains the relative paths inside the EXE (with vi.lib stuff going in a 1abvi3w folder). The exact structure of an EXE is a bit more complicated, but you can see this behavior if you look at the build folder while the build is happening (although that might end up messing your build up).
The practical upshot of this is that if you want to include something in the EXE without loading it statically and then load it, you can simply place a VI in a known relative location (for instance, in the same folder or a parent folder) and use the path of that VI to get your final path. That VI can be called statically and the behavior should be the same in LV and in the EXE, as the paths of items included in the EXE are stored relatively.
This is meant as a plugin system, so no static VI refs.
12-15-2025 08:05 AM
@Yamaeda wrote:
This is meant as a plugin system, so no static VI refs.
If all of your plugins are included at build time inside the EXE, you can still do this. The static VI doesn't have to be a part of any specific plugin, just something used to find the path for the plugins.
If you want to then have a list of the plugins, I can think of two options:
* I haven't checked how to do this. It might be a tag in the build spec or it might require using the AB API VIs, which you probably can't. I suppose you could also extract it from the LVPROJ XML data.
12-18-2025 06:16 AM
@tst wrote:
@Yamaeda wrote:
This is meant as a plugin system, so no static VI refs.
If all of your plugins are included at build time inside the EXE, you can still do this. The static VI doesn't have to be a part of any specific plugin, just something used to find the path for the plugins.
If you want to then have a list of the plugins, I can think of two options:
- List folder. I'm not sure if this will work inside the EXE.
- Have a pre-build VI which takes the list of plugins (for instance, by reading the always included items list* or building it some other way) and then set that list as the default value in an indicator connected to the connector pane in a VI and save that VI and call it in the build to get the list.
* I haven't checked how to do this. It might be a tag in the build spec or it might require using the AB API VIs, which you probably can't. I suppose you could also extract it from the LVPROJ XML data.
#1 doesn't work
#2 is what my collegue does now, i hoped there'd be a niftier way. 🙂