Mellroth Posted August 20, 2018 Report Share Posted August 20, 2018 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 Quote Link to comment Share on other sites More sharing options...
Jim Kring Posted August 20, 2018 Report Share Posted August 20, 2018 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. Quote Link to comment Share on other sites More sharing options...
Mellroth Posted August 21, 2018 Author Report Share Posted August 21, 2018 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 JKI example.zip Quote Link to comment Share on other sites More sharing options...
Jim Kring Posted August 21, 2018 Report Share Posted August 21, 2018 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. Quote Link to comment Share on other sites More sharing options...
Mellroth Posted September 11, 2018 Author Report Share Posted September 11, 2018 Have you been able to reproduce the bug with the files I uploaded? /J Quote Link to comment Share on other sites More sharing options...
Ashish Posted October 26, 2018 Report Share Posted October 26, 2018 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? Quote Link to comment Share on other sites More sharing options...
schliepe Posted July 2, 2019 Report Share Posted July 2, 2019 I'm wondering if any solution to this was ever found? I've run into a similar situation and am looking for solutions. Thanks, Erich Quote Link to comment Share on other sites More sharing options...
Ashish Posted July 8, 2019 Report Share Posted July 8, 2019 Erich, What version of LabVIEW and VIPM are you using? Can you confirm that the code example shared above is same as your issue? Quote Link to comment Share on other sites More sharing options...
schliepe Posted July 8, 2019 Report Share Posted July 8, 2019 Hello Ashish, I did just run the example and I get the same error. I am using LabVIEW 2016 and VIPM 2019.0.0 Let me know if there is anything else I can do to help solve this issue. Regards, Erich Quote Link to comment Share on other sites More sharing options...
schliepe Posted July 8, 2019 Report Share Posted July 8, 2019 As another point of data, I even installed the internal VIPM into my LabVIEW installation and then changed all of the calls within the Public VI to use the files from the installed package and then rebuilt the Public package and got the same error. We are actively trying to search for a solution here, so I'm happy to help try some things if it helps to come to a resolution. Thanks, Erich Quote Link to comment Share on other sites More sharing options...
Ashish Posted July 9, 2019 Report Share Posted July 9, 2019 Erich, I was able to successfully build the package from the source that was provided by you. I am using LabVIEW 2016.0f5 (32bit) and VIPM 2019.0.0. Can you try the attached package that I was able to build successfully. wireflow_lib_wf_internalclasses-1.0.0.2.vip Quote Link to comment Share on other sites More sharing options...
schliepe Posted July 9, 2019 Report Share Posted July 9, 2019 Thank you Ashish, I tried to build the package by clicking the "Do Not Compile on Build" and got the VIPM - Product Activation window. I take that to mean that at the moment there is no way to do this without having a license for the Pro version of VIPM. Is that a correct assessment? Erich Quote Link to comment Share on other sites More sharing options...
Ashish Posted July 10, 2019 Report Share Posted July 10, 2019 Yes. You can make use of 30 Days evaluation to test that specific feature and ton of other cool aspects of VIPM Pro! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.