Jim Kring

Hi @kosist. Thanks for reporting this. We've logged a bug [18812] for this issue and will have our team look into it. Regards, Jim

Sometimes there are weird permissions issues in Windows with files on a network drive. I've noticed odd behaviors occasionally, too. I'm glad it's working for you now, and thanks for reporting these issues.

Hi @elmachin. Are you able to choose the option to continue without sign-in? There are some corporate IT environments where the sign in does not work. Also, can you check the C:\ProgramData\JKI\VIPM\error folder for a file with the most recent date in the name and share it? That may help us understand the issue.

Hi there. Hmmm, there are several possibilities. 1) Remove the external package dependency (in VI Package Builder >> Dependencies setting) You can make a package an *internal* dependency in the VI Package Builder (go to the dependencies page and remove it from the list of dependencies, and then VIPM will transparently build those VIs into your distributed package) 2) If the VIs in that library are kept beneath your VI Package Source Folder, then VI Package Builder should build them into your package. You'll want to be sure they get "namespaced" differently (by renaming the lvlib or putting the lvlib inside another lvlib for your tool) so that the library's VIs don't collide with an installed version of that library on the end user's development machine. 3) Also, I see there are newer versions of this tool available and one is available in VIPM. - Tree-API << this is a VI Package, but I don't think it's hosted on vipm.io - Tree Map << this is the newest and *is* available on vipm.io for installation with VIPM Would upgrading to use the Tree Map work for you? Then you could just make this a dependency that your end users will be able to install.

Glad that worked for you!

Hi @felipefoz. You can use the VIPM API to query this.

Hi There. I think you may need to also (separately) publish the system package to the repository, too, in order for it to be correctly downloaded/found by repository clients. Please try that, and let me know if that resolves the issues for the clients.

Hi @Rami_Saaidi, We've had another user report a similar issue recently. Have you tried re-running the installer after the error, to see if it works the second time? Also, I think one user said they resolved the issue by installing .NET 4.0 before running the VIPM installer. -Jim

@Ruslan. Thanks for reporting this. Do you know if this also happens in newer versions of LabVIEW, too (e.g. LV 2020)?

I see. Could you change your individual packages (that require none of their VIs are in memory) to require that LabVIEW be closed before installing?

Hi @ranjgith. No, there's no such feature for VI Package Configuration files. Packages, themselves, have such features but not VIPC files. Can you explain a little bit about what you need to accomplish? What's your use case? -Jim

Hi @wolfkil. Thanks for letting us know it worked for you. We're trying hard to keep things working well. Please let us know if you have any more issues.

Hi @Olivier Jourdan. I have no idea why this setting wouldn't work. Can you try it on a super simple project to see if it's reproducible? If you can reproduce it and zip up the sample project, we can take a look.

Fantastic! Thanks for lettings us know.

@mprantl Install stats are shown in VIPM 2020's VIPM Browser and on the package pages of vipm.io

This is available in VIPM 2020 available for download: vipm.io/download

@sblades this is fixed (we hope) in VIPM 2020.1 now available for download: vipm.io/download

@StefanLemmens - this feature is in VIPM 2020.1 which is now available for download: vipm.io/download

Hi All, @QsiAtWork, @Nstewart, @szymsciupak, @Mads Toppe, @wolfkil VIPM 2020.1 for Windows and Mac are available for download at vipm.io/download This new version allows download without sign-in, to allow corporate users behind an IT proxy/firewall to download/install packages. Thanks for your patience. -Jim

Another thought... you can append text to VI Descriptions via this setting in the package builder.

Hi Olivier, My first thought is that this would probably only work for a post build custom action (unpack the VIP, modify the VIs, and repack the VIP). -Jim

Hi @Paul Torek. We did have some issues with VIPM 2020. There should be fixed/improved in 2020.1. You can get the latest release candidate and help us test in the VIPM 2020 beta forum. Sign up here to get access to that forum.

Hi @drjdpowell, @jb1592, Sorry for the issues. We're working hard on VIPM 2020.1 and hopefully this issue will be resolved. It's odd that the package builder window opens, yet the VIPM main window and the system tray icon aren't showing. I've heard a few other reports of similar behavior and we've got it on our radar. I don't think it's related to the "Error 42 occurred at (http response "404". URL Requested)" -- I think that was an issue with a missing file on NI's LVTN package repository. Regards, -Jim

Hi @Vollinger. The issue is that LabVIEW addresses items in the palette by their display name. So, if two items have the name "Connect.vi" then LabVIEW will show the first one it finds, even if it's for a different toolkit. The solution/work-around is to change the palette display name of your "Connect.vi" to something like "Connect (MyComponent)". Here's where you would change that name in the palettes, via the palette editor. Does that work for you?

HI @JMA_1. We made some major installer improvements in VIPM 2020.1. We have a release candidate available for download in our beta testers forum -- sign-up here to access that forum. Thanks and hope we can get you working quickly!