Jump to content
Mellroth

Internal Dependencies and error 1357

Recommended Posts

We recently hit a really big bug (at the moment it is a showstopper) when trying to build a new package with a number of internal dependencies.

* LV2014

* VIPM 2016

What happened was that VIPM complained about VI salready in memory, throwing error 1357, for several files in the dependency hierarchy. We were able to nail it down to that VIPM puts all dependencies in a flat structure. This means that if you link to a dependency with a class hierarchy and dynamic dispatch, all dispatched VIs will be placed in the same flat structure and thus getting the error 1357.

We even tried to workaround this by putting each class in a separate llb when building the vip file of the internal dependency.

This probably affects other types of packages, e.g where name-spacing via lvlib is used.

I haven't found anything about this being a known issue, so please update VIPM to preserve the hierarchy of the dependencies, or at least handle a scenario with internal deps with name duplicates

/J 

 

Share this post


Link to post
Share on other sites

Hi. Thanks for reporting this. Would you be willing to spend a small amount of time to create a super simple VI Package project that demonstrates this issue and share that with us (as a zip file)? We'd love to be able to reproduce this issue and see if there's a work-around or fix.

Share this post


Link to post
Share on other sites

Hi,

 

Attached is a simple example using the LabVIEW DynamicDispatch example as source. The internal package contains the three classes Shape, Triangle and Square. All these classes have a method named Identify.

The public code is supposed to use these three classes internally, but not expose them, hence we add them as an internal dependency.

If the wireflow_lib_wf_internalclasses-1.0.0.1.vip is added as a internal dependency, the build of the public package fails with the error shown in the attached image, if we remove the package from the list of dependencies the public package package builds just fine.

If we monitor the VIPM temp build folder during the build, and if we check other internal packages, we see that the folder where VIPM puts the internal dependencies and adds the name-spacing is a flat structure. Since several methods have the same name it means that they will still have the same name after the name-spacing, resulting in the failed builds

/J

 

Screen Shot 2018-08-21 at 07.57.25.png

JKI example.zip

Share this post


Link to post
Share on other sites

Thank you. We'll take a look at reproducing this and if there's a future fix for the issue. We can't commit to a timeline, but we certainly would love to see this issue addressed in a future release, if there's a solution to be found.

Share this post


Link to post
Share on other sites

Hi,

Sorry for the delay in getting back to you. I was struggling on why VIPM was opening LabVIEW 2016 when I had selected LabVIEW 2014 in VI Package Builder. I later figured that the VIs are compiled in LabVIEW 2016. No wonder, VIPM was trying to do its best to build the package.

Can you confirm the LabVIEW and VIPM version to test?

image.png

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use.