Jump to content

RocketHacker

Members
  • Content count

    19
  • Joined

  • Last visited

  • Days Won

    1

RocketHacker last won the day on July 25 2013

RocketHacker had the most liked content!

Community Reputation

1 Neutral

Profile Information

  • Gender
    Male
  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 solution that automatically does this. just looking to file this as a bug report.
  2. VIPM Aborts build on 'open' vis

    brilliant! I'll look into my failed builds to see if i'm hitting the same issue. thanks!
  3. VIPM Aborts build on 'open' vis

    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 annoyed by this until i realized that i had wasted about 20 hours trying to get it to work initially. the extra 5 min to do the source distribution is way less painful. but, seriously, jki needs to fix this bug. i'd give more details about what causes it, but even after 20 hours of mucking with it i still have no idea what triggers it to do this.
  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 packages update all tools to point from dependency source code to dependency packages (this will take some time) NoDetectSecondDependency.zip
  5. rename VI dependencies

    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. custom action dependencies not included in build

    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. (system) package?

    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. (system) package?

    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, so the installer will actually find the file from its source location. if it pulls in the files not included in the package, we've completely lost configuration control! it seems to me that the installer should never search for VIs and just error out, but maybe that isn't an easy task?
  12. rename VI dependencies

    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. rename VI dependencies

    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 packaged
  14. rename VI dependencies

    Vote on the idea related to this ticket here http://ideas.jki.net/topic/167846-rename-dependencies-without-renaming-package-files/
  15. rename VI dependencies

    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 most affected by this problem... [*]X.vi will eventually become a VIP. no question about this. The issue is that the process of packaging, deploying and validating each package cannot be performed in a single quick step where the normal rules would apply. workflow is: build X.vi into X.VIP re-link and rebuild packages that use X.vi to X.VIP re-link 50+ applications to X.VIP update VIPCs for all applications to include X.vip deploy new VIPCs and update applications on 50++ servers the applications are used on (we use dev environment for most deployments. reasoning is outside the scope of this post) for our code base this process can take days per package. We cannot devote all of our time to this task, so we have to assume that it will get interrupted by more immediate tasks, resulting in the need for code merging, etc. Having the ability to easily switch between source <--> package (when the package files are not the same name) would be a viable fix for this problem. Can you PM me with more information on availability of this feature? I have made a lot of promises about VIPM to my management (seemed like a good idea at the time...). Since this is a blocking issue, I need to give them some idea of the plan forward and a timeline to match. If you need clarification of any of the above, let me know. The more i help you, the more you help me
×

Important Information

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