Loading plugins as PPLs gives dependency issues

[Basjong53]

I'm trying to learn using PPLs to speed up my deployment process, but I've ran into some problems. I'm following this excellent guide, yet I still I'm still not able to get it working without problems.

The example program seems very simply. It uses a PluginInterface.lvlibp containing a parent class. Plugin 1.lvlibp contains a child class of PluginInterface.lvclass. In the Plugin1 project, I've loaded PluginInterface.lvlib and Plugin 1 inherits from the class inside the PPL.

Testapp.vi tries to load Plugin 1.lvlibp from disk as follows: 

The path is loaded correctly, and "Get Exported File Path.vi" correctly gets the class path within the PPL. The problem is that loading the plugin PPL gives the following dependency conflict:

Clicking add loads Plugin 1.lvlibp into to the project with the mentioned conflicts. If I then remove Plugin 1.lvlibp again from the project while testapp.vi is still running, it remains in the "Items in memory" folder. How can I make sure I don't get the confict warning? Because when I make the vi into an .exe the program works without warnings.

I guess it has something to with location of each of the PPL on disk and there are conflicts when they are not able to load from the expected path. So how can I avoid these issues? What are the best practices for this case?

[l.hovs]

Hi Basjong53, 

LabVIEW scans the VI hierarchy when you open the block diagram of a VI and add a new subVI. The subVI does not load if any members of its hierarchy have the same qualified name but different paths as an item already in the project. The Add to Project and Update Dependencies dialog box appears. You can add the hierarchy or cancel the load and choose another subVI.

For more information follow this link.

Regards)

________

Best way to thank is giving Kudos / Marking as a solution. 

[crossrulz]

You are probably running into issues with the fact that your PPLs are getting moved around.  They have to retain relative paths to each other through the entire process.  So I would get rid of the PluginInterface.lvlibp from the PluginInterface directory and use the copy that is already in the build directory (have it build into the builds directory instead).  In the build specifications for the plugins, go to the Additional Exclusions tab and check the "Exclude dependent packed libraries".  They can then rely on the interface PPL being in the build directory already.

[IlluminatedG]

l.hovs, you're frequently posting links to questions that are related but not very helpful. For instance, in this case, the linked concept guide mentions nothing about managing PPL build dependencies. Try looking for more context to issues in the future or replicating some things yourself and trying the solutions before you link them. Then watch the kudos and solution marks start rolling in.

[Basjong53]

It's been a while since I've posted this question. I have been using PPLs a lot more now and don't have this problem anymore.

 I don't remember exactly what the issue was, but probably the child class was wrongly linked to the parent class in the PPL or something.