Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


RocketHacker last won the day on July 25 2013

RocketHacker had the most liked content!

Community Reputation

1 Neutral

Profile Information

  • Gender
  1. I've built a custom package and set it as incompatible with a 3rd party package. VIPM doesn't recognize the conflict on installation of my package, but acknowledges the conflict via icon after the install. clicking the icon and selecting "Install missing dependencies" just gives a dialog saying "There is nothing to do. All the packages are already installed". If I were not he original author of my package i would be very confused what was going on here... running VIPM 2016.0.0.1986 Of course the manual workaround is to manual uninstall the conflicting package, but i'm trying to get a so
  2. brilliant! I'll look into my failed builds to see if i'm hitting the same issue. thanks!
  3. i've ran across this and never was able to distill it down to a root cause. i know that it has something to do with having dependencies outside of the package source folder. i was able to successfully work around it by: create project for source files put source files into that project build source distribution of source filesadd source files to always included section in source file settings, put dependencies in support directory. apply name prefix to prevent name spacing issues later [*]build vi package from source distribution this sucks because it adds an extra step. i was ann
  4. here is a set of files exhibiting the bug. steps: extract all files open package\.vipb goto "package dependencies" scan for dependency changes notice how no dependencies are detected this project has a package dependency on open g time library i'm using VIPM 2013.0.0.1893 my workflow would ideally not allow secondary dependencies like this, but since i am migrating 3k VIs into a hundred or so packages, it is something i'll have to transition through. my migration plan is: build every tool into a package. leaving all dependencies linked to source code switch over applications to use
  5. Quick update on this ticket. With the introduction of the PMT (https://decibel.ni.com/content/docs/DOC-30858), we have no issues with renaming files any longer. We no longer need this request fulfilled.
  6. Good to hear that you're familiar with the issue! We're starting to migrate our 3k++ VIs into VI packages. This bug is a near-blocker for us at the moment. We can work around it, but it is going to add extra steps to our package validation process and increase the likelihood of bad packages getting out into the wild (and make VIPM look bad ). We'd appreciate any efforts you could put toward getting this one resolved. let us know if you need any more information or need us to do any beta testing. Thanks!
  7. ok. lets see if i can explain this clearly... i am trying to build A.vi into package A.vip. A.vi has a dependency on B.vi B.vi is not in the same folder as A.vi or the .vipb file for A.vip B.vi has a dependency on C.vip In the .vipb for A.vi, when i click "scan for dependency changes", C.vip is not detected as a dependency when A.vip is built, NO files from C.vip are included The workaround is to manually include C.vip as a dependency, but then why am i buying the pro version... is this expected behavior?
  8. sweet. i'll build my custom actions dependencies into a package and include that package in the build. any chance the "autodetect dependencies" option in the pro package could detect dependent packages in custom actions?? i know that at some point i'm going to forget to include the package. you've got a really good point about the search paths. i'll have to reconsider. we originally added our dev directory to our search paths because it is very painful to relink things manually when files are renamed and it net'd a time savings. maybe we could just get better at naming things...
  9. excellent! i'm glad this is not an issue. you may want to update your documentation to include the phrase "(system)" in it. i searched your entire website for that phrase and came up with nothing. well, of course, now this post will be returned...
  10. i create a package to install some glyph files my team uses. when i install it, it adds this additional (system) package that i didn't create. what is going on here? should i be concerned?
  11. i have custom actions in my build specification. these actions have dependencies that are not in vi.lib, nor in the package. when i install the package, it tries to find these dependencies. this leads me to believe that custom action dependencies are not included in the build? what should i do here? unpacking all dependencies to only include vi.lib code isn't a viable option. secondly, and perhaps the scary part, when the package is installed and the dependencies are not found, labview will search for the VI. in my case, i have my main development directory set as a search path in labview,
  12. agreed. my plan is to lock all package VIs in a post-install action. this will make it pretty obvious which ones are packaged even if they have the same name as the source files here's the idea related to the locking feature http://ideas.jki.net/topic/167870-allow-locked-no-password-protection/
  13. if the packaged file has renamed its dependencies, there will not be a name conflict with the old-nonpackaged version. A.viphas dependency X.vi that is renamed and packaged as A_X.vi[*]B.vip has dependency X.vi that is renamed and packaged as B_X.vi[*]Application.vi has dependencies X.vi A.vip that uses A_X.vi B.vip that uses B_X.vi so, as long as we can rename dependencies only, there will be no conflicts. you don't have to worry about using differing versions of X.vi because the version that was included in each instance was (hopefully) exhaustively tested to work when it was packag
  14. Vote on the idea related to this ticket here http://ideas.jki.net/topic/167846-rename-dependencies-without-renaming-package-files/
  15. X.vi is a piece of reusable code that is shared by applications and other reusable code. They all link to the same location. I can't rename files when i package them. The manual re-linking effort is prohibitive.reusable code is used in reusable code reusable code library is used in 50+ applications no easy way to switch back to source code and debugcan't edit the package files directly. due to the differing names, changes can't be easily ported back into version control (SVN)[*]coincidentally, the code that needs to be distributed by VIPM the most is used in the most places and is mos
  • Create New...

Important Information

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