Jump to content

Jim Kring

JKI Team
  • Posts

    2,199
  • Joined

  • Last visited

  • Days Won

    105

Everything posted by Jim Kring

  1. Thanks for reporting this. I haven’t heard of this one before, and it seems like something for which we need to loop in NI, since it appears to be something NIPM is looking for and I don’t know about the internals of that. Let me reach out to NI and see what I can find.
  2. Hi James. I'm sorry this still isn't working well for you. Thanks for reaching out to let us know. This has been a wild couple of months for everyone, so thank you for your patience. Understanding and fixing these issues is important, and I'll do my best to help resolve the issues. My understanding of your goals/issues are the following: --- Goals To be able to use VIPM API in a CI context to achieve the following: A ) Create a package configuration for a project A.i) Scan a Project for Dependencies A.ii) Create a VIPC file of the found dependencies B ) Apply a package configuration for a project B.i) Apply a VIPC file for a project B.ii) Install packages before building a project Issues There are some problems encountered along the way: 1) The UAC gets triggered (probably due to the Registry update service) 2) Silent mode is not respected (a bug) --- Did I miss anything? For Issue #1, we might be able to resolve this by adding a configuration setting (INI file key) to suppress the launching of the registry update service when VIPM starts. I'm not sure why VIPM is running that at every launch, and it certainly doesn't need to do that in a CI context. For Issue #2, can you provide a little more information about which step above is causing dialogs to show (even when silent mode is specified) that need to be suppressed? Thanks again for reporting these and for your help as we work through trying to resolve them. -Jim
  3. Hi Ivan. Yes, VIPM checks the package integrity. I think it must be an issue that VIPM Community is not running the post-build custom actions. I'll have our team look into this as well. I'll ping you offline about how we can get a work-around for you.
  4. OK, I think we're getting closer to figuring this out. It appears that when VIPM Community is activated the Restart LabVIEW setting is not being applied correctly to the built package settings -- this is a bug. It'll file a bug for this and have our team look into.
  5. Also, it's worth noting that post-build custom actions require VIPM Pro or Community, too, and won't work in VIPM Free.
  6. Hi @kosist. I think I figured it out. The options on the "Advanced LabVIEW Requirements" area only supported in VIPM Pro. My guess is that this .vipb was created with VIPM Pro, but the copy of VIPM you're using is not activated as VIPM Pro. VIPM will still build the package if you have VIPM Free activated, but it resets those flags to FALSE during the build. Try toggling the checkbox for that setting to FALSE then TRUE and you'll probably see this dialog stating that it's a VIPM Pro (and Community/Non-Commercial) feature: Hope that helps. -Jim
  7. Thanks for that extra info @kosist. We're going to look into this much deeper, but I wanted to give you a quick response with a possible work-around. If you create a post-build custom action (Note: This requires VIPM Pro or VIPM Community, and won't work with VIPM Free) you can unpack the package (meaning: unzip the .vip file to a folder), modify the spec file (set the "restart labview..." key to TRUE), and then repack the package (zip it back up into a .vip file). Please let me know if this makes sense or if you need help. Here's a screenshot of how you would call this in your post-build custom action (except you would modify the "spec" file contents instead of the MNU file shown in the example): Unpack Package.vi Repack Package.vi
  8. Hi @kosist. Thanks for reporting this. Can you explain a little more about what you're seeing in 2020.3? You said, "when I install it - project is restarted" and that part about the project confused me. Are you saying that when you install the package only the project gets restarted (but LabVIEW is not restarted)? If you can, please be sure to report: Steps to reproduce (is there a public package that reproduces this issue?) What you expected to see. What you saw/observed instead. Thanks, Also, a quick thing you could check is to see if the spec file inside the package (open the *.vip file with 7-zip and look at the spec file) to see if the Restart LabVIEW key is different/missing. -Jim
  9. I’m glad to hear that this fixed the issue. Yes, ideally it would work a little bit smarter/better at refreshing itself automatically.
  10. "Types and Defaults" is the LabVIEW Data type that you want to populate with the JSON data wired in. Please take a look at the examples.
  11. Hi @RochelleS Yes, users have reported some issues with NIPM and how it tries to install VIPM. We recommend users install VIPM using JKI's installers and not NI's. A few things: 0) Can you check the "C:\ProgramData\JKI\VIPM\error" folder to see if there's an error log file with today's date on it? Can you attach that file here, so we can take a loot? 1) Regarding the connection to the NI LabVIEW Tools Network, can you try again (press the "Refresh" button) and confirm whether it's working? I just tested an it's working OK for me. 2) Which version of VIPM are you using? Windows or Mac? 3) What setting do you have for "Configure Proxy to Access the Internet"?
  12. Hi Anthony, There was an issue in older LabVIEW versions (~LV8.x) where it had to save class Dynamic Dispatch methods into separate folders. In newer LabVIEW versions, there's an option to do the same thing. Perhaps that option is set to TRUE in your build settings. Try setting it to FALSE and see if it fixes the issue.
  13. That button/form is for publishing open source packages to the VIPM community repository. Some of the packages on VIPM.io are hosted on the NI tools network repository. You’re right that those buttons should probably be disabled for commercial packages hosted on the NI tools network.
  14. I think I see what you're saying -- if an older version of the package is published in a repository, but the installed/latest (i.e. displayed) version is not published, it would be helpful to know that it's a development version that's not yet "officially" published to the repo. This is different, perhaps, than a package where no versions are published. Idea: Maybe VIPM should display "Local" as the Repository name if no versions of the package are published. This deserves some more thought, for sure. I'm glad you have a workable solution, for now. Thanks for sharing these ideas. P.S. Yes, there have been some dragon signings lately
  15. Hi Laurent, Can you look in your error log folder to see if there's anything helpful in there? C:\ProgramData\JKI\VIPM\error Thanks for your patience and help debugging this. -Jim
  16. Hi @kosist. I agree that it's important to know if a package is not published. Right now, I think you can tell by looking at the "Repository" column and it should say "Unpublished" (as shown in the screenshot below). Is there somewhere else you'd like to see this "Unpublished" status more prominently?
  17. You're welcome @kosist and please keep sharing your ideas! It's a big help to the community
  18. This can happen if Windows Update is installing stuff behind the scenes. Is this a corporate IT controlled computer? Please try again after a while and see if that helps. Also, can you try uninstalling VIPM 2020.2 from Windows Add/Remove Programs?
  19. Updating this thread with an example post-install custom action that modifies Call Library Function Node paths. Example File: Post-Install Custom Action.vi Screenshot:
  20. Thanks for posting this great idea. Since it was a simple fix, we went ahead and made the change. Please try it out and let us know how it works for you.
  21. OK, great! Glad you were able to get the latest version. The latest version should hopefully also fix the issue with Check for Updates on Mac. Likewise, thanks a bunch. -Jim
  22. It's a good question. VIPM 2017 works with LabVIEW 2017 and older. So, you need VIPM 2020 to install packages into LabVIEW 2020. We don't have a VIPM 2020 for Linux, yet. What a lot of people do as a work-around is install LabVIEW 2017 on Linux, use VIPM 2017 to install the packages, and then copy them over to LabVIEW 2018-2020. Another, similar, approach is to install the packages on Windows or Mac machine and then copy them over to Linux. Thanks for your patience and understanding on this.
  23. Yes, a basic CI integration would be to know if any tests fail and abort the build. More advanced would be to output a results.xml file and have the CI system give details on which tests are failing.
  24. Might be good to make that VI public. FYI: @Francois Normandin
×
×
  • Create New...

Important Information

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