08-30-2019 05:32 AM
Hi all,
Please bear with me while I quickly explain the situation:
The issue is based on the case where a ppl has a dependency that resides in a folder “higher up” than itself. For example, lets consider that [PPL_1] sits in the \bin folder in: "C:\Folder1\Bin\Folder3" and its dependency resides in "C:\Dependency".
Two scenarios can happen if you try to open the PPL:
Essentially, when the relative path of a dependency ‘hits’ the highest level (C:\) LabVIEW seems to fail to even recognize it as a path and gives you no option except quit.
We have reasons to believe that this is introducing issues with our Continuous Integration system, in which projects and packages are built in quite deep locations, and then end up impacting immensely our development environment. Please see the attachment with an example of this: if you extract it in your C: drive you will see what I mean.
Now, I doubt that this is intended behavior, but I was wondering if anyone had an input on this.
Thanks as always,
09-02-2019 04:05 AM
Hi crandiba,
It may comes from your user permissions. Sometimes you don't have the permissions to do action on some folders.
Try to open it with administrator privileges.
Have a nice day!
Clement
09-02-2019 03:35 PM
I don't have time to test this at the moment. Though, I'm curious if it's related to how deep the original code's file structure is.
In other words, let's say I develop the lvlib in: c:\dev\folder1\folder2
The dependency resides in c:\dependencies
If I place the PPL into a folder such as: c:\otherPC\folder1\folder2, does that work? If I move it to c:\otherPC\folder1.. does it stop working? Similarly, if I move it to c:\otherPC\folder1\folder2\folder3, does it work?
Given the usage of relative paths, I'm curious to see if there's an issue with the hierarchy itself causing pain if the height of the folders changes between lvlib and lvlibp.
You can likely put together a quick test to confirm/deny this theory. If so, you at least have a workaround (add a dummy folder)
09-03-2019 01:44 AM
Hi,
thanks all for the suggestions:
Sadly, not a permissions issue, I'm afraid.
It is also not related to the "absolute" depth/folder level - only to the actual difference between the expected relative path to the dependency and your "C:\" drive: if you move a built PPL "higher up" in a way that it would make the relative path to its dependency go over the limit, it becomes a <NotAPath> and doesn't even try to load it.
Hope that made sense,
09-03-2019 08:09 AM
If you use a VI ref-constant i can't really see how this would fail, or are you using Path constants or similar?
/Y
09-17-2019 05:08 AM
Hi all,
So finally got confirmation from NI regarding this and they opened a CAR for it. In fact, its related to another CAR regarding issues with placing a PPL in <vi.lib> or <user.lib>.
I'll keep you updated if/when a solution is found.
Thanks,
09-17-2019 10:26 AM
We encountered this issue before and managed it by using very well defined locations for our PPLs. We created a folder structure that is essentially mirrored to support development and deployed applications. Our folder structure maintains the same depth between all PPLs and their dependencies. We have approximately 170 PPLs with a hierarchy about 10 levels deep. Needless to say it is a complex environment. The PPls are divided between what we call libraries and plugins. The libraries contain core reuse libraries and base classes. The plugins are all dynamically loaded PPLs. Our largest struggle when creating this was the issues with how relatives paths were handled.
09-18-2019 04:25 AM
Hi Mark,
Sounds exactly what we are trying to do - and arriving at the same workarounds. Its unfortunate that we need to keep this structured the same to avoid issues, and actually leads to problems with our automated builds that actually performs the builds at a different staging area depth. Thanks for the feedback I'll keep you updated.
09-18-2019 10:04 AM
We have our build process fully automated on Jenkins. What we found extremely useful is to also use MGI's Solution Explore. That helps to build things in the proper order. One of my co-workers is in the process of developing a tool which will automatically determine the dependency hierarchy of PPLs and the proper build order. We hope to have this complete soon. We will have to clear with management whether we can release it to the public.