LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Packed Project Library bug with Relative path: Failed to Load

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:

  1. If you decide to open PPL_1 in a folder location "deeper" than the one it was built (for example, an imaginary …\Folder3\Folder4), LabVIEW will prompt you to locate the dependency.
  2. If you try to open the PPL_1 in a folder “higher up” that the one that it was built (for example, Folder2) it will simply state “Cannot be opened”.

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,

 

0 Kudos
Message 1 of 9
(2,686 Views)

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

0 Kudos
Message 2 of 9
(2,623 Views)

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)

 

 

0 Kudos
Message 3 of 9
(2,603 Views)

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,

0 Kudos
Message 4 of 9
(2,588 Views)

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

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 5 of 9
(2,574 Views)

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,

 

Message 6 of 9
(2,546 Views)

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. 



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 7 of 9
(2,528 Views)

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.

0 Kudos
Message 8 of 9
(2,510 Views)

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.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 9 of 9
(2,480 Views)