Missing files when building an executable that uses PPLs

[matt.baker]

I started making Packed Project Libraries (PPLs) with linked PPL dependencies rather than embedding copies in each PPL.

Each PPL is built to a separate child folder within a common parent folder used for all re-usable PPLs. This was done so that non-LabVIEW type dependencies such as DLLs and executables required by the PPL don't all end up in one big directory.

E.g.

Packed
Packed\PPL1\PPL1.lvlibp
Packed\Instrument control\PPL2\PPL2.lvlibp
Packed\Instrument control\PPL2\Depend.dll
Packed\Instrument control\PPL3\PPL3.lvlibp
Packed\PPL4\PPL4.lvlibp

In the example above, PPL2 and PPL3 both depend on PPL1 (linked not copied).

When I build an executable that uses a PPL that links to another PPL (as above), it complains that files (functions, classes etc.) are missing. I thought LV was supposed to handle this when building an executable and adjust the paths accordingly or search the base/data directory for a matching PPL.

I notice that when the executable is built, all (modified?) PPLs are placed in the same directory by default.

If I try to manually specify the PPL (just for testing, not a working solution) I get the following error:

Or

I'm sure I'm missing something obvious, or maybe this use case is not handled?

[crossrulz]

There is an option in your build specification to include PPL dependencies.  Make sure that is turned OFF.

[matt.baker]

Do you mean this option in the executable build?

If I enable the option to exclude PPLs the executable will only work if the PPLs are in the exact same paths on both the build and deployed machines. I wanted the contents of executable build folder to be enough to make it portable (if you ignore the LV run-time).

I was hoping LV PPLs behaved like DLLs and searched in a similar order to this: https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-search-order#standard-sea...

That way it doesn't matter if they all eventually get bundled into a single directory during build/deployment.

[crossrulz]

---

@matt.baker wrote:

I was hoping LV PPLs behaved like DLLs and searched in a similar order to this

---

Unfortunately, that has not been my experience.  All relative paths must be maintained between the executable and any PPLs it calls.  And any PPLs that other PPLs call must also maintain the relative path.  Yes, it can quickly turn into a big giant mess.  I am hoping NGX fixes this.

[matt.baker]

I'm quite relieved that you've also experienced this, so must be by (bad?) NI design. I was starting to think my machine had build issues or some weird configuration. Although, still not completely convinced that there isn't something still wrong with it as when I rebuilt and tested the cut-down PPL test I started at work on my home PC, it seems to work.

Also a bit peeved now that it looks like there is no simple fix. Lots of time spent migrating libraries over to PPL and relinking etc. only to fail at the last hurdle. In hindsight I should have started smaller and tested the build process fully without assuming it would all work as expected, but based on what I'd read, it looked like the perfect fit

Hopefully no NXG for me. Mid/long term plans to migrate over to C# in Visual Studio.

[crossrulz · Accepted solution]

---

@matt.baker wrote:

Also a bit peeved now that it looks like there is no simple fix.

---

Sure there is.  I just have all of my builds to into a special Builds folder and maintain the directory structure I want for my final application.  I have had no problems since.

[matt.baker]

Do you mean for the PPLs? And just put them all into the same output folder on build?

[crossrulz · Accepted solution]

---

@matt.baker wrote:

Do you mean for the PPLs? And just put them all into the same output folder on build?

---

And for the executable as well.  Remember, it is the RELATIVE path that matters.  So as long as you are consistent with the relative paths between your builds and the final application, you will be fine.

[Alexander_Sobolev]

I usually do not exclude PPLs, Labview places it and makes main app know where it is.

But then I copy original PPL build over new one. It solves path issues. I need this, because new PPL is different (dlls paths have changed, some vis might have been excluded, etc).

For complex relative paths (PPL2 used not only by PPL1, but also by main app) I still have to configure PPL2's location in main app build.

Complex builds configuration is really inconvenient.

[YinhuiChen]

Hi Matt,

1. The trick to solve your problem is to create Destinations and link them to dependent PPLs in Source File Settings. With these settings, you can keep the file system hierarchy as in your design. You need to be aware of the nature of how LabVIEW is using relative paths. 

2. Regardless of enable or disable the Exclude dependent packed libraries, LabVIEW will use relative paths for sure! The only difference is LabVIEW will copy the dependency PPLs to the destination if this checkbox is unchecked. In this case, DO NOT set the destination as where it is already located, otherwise LabVIEW will error when build saying the ppl can not be copied and overwrited.

3. It is a bug in LabVIEW that installer source from executable's build spec, it will bring in all PPLs. Those PPLs are locked in the installer's build spec and you can not remove them from distribution. These PPLs being installed to <ProgramFiles> are also not in use if you have set them in other destinations. The way to solve this issue is to separate the project into 2 that one contains the executable build spec and one contains the installer build spec that uses compiled executable and PPLs. This way, LabVIEW won't be smart enough to process your already compiled executable and bring the PPLs along to <ProgramFiles>. This solution should be used when you want to distribute you PPLs to other locations than next to the executable.

Thanks,

Yinhui Chen