Leaderboard

Some advanced users are asking for support to install VIPM for Windows onto a Docker container. This would allow creating fully automated build processes that spin up virtual machines that have LabVIEW and VIPM installed on them, so that VI Packages can be created automatically.

Main package list.. i noticed there is update available will see how that goes after update. Thanks..

Hi guys, I've written this small wrapper for Run Tests Programmatically which I can just drop in any of our projects, it will find the uni tests in the folder structure and run them. It works perfectly except there is no way to change the result format of the test results. This wrapper also drops the results into the repo so they will be part of the commit/pull request and easy for the reviewer to see. The text result format would be easier to see in Azure DevOps than XML. Is there a way to change the result format for this vi (other than hack it with vi server)? It seems to be

Here was last answer from IT which solved my problem : Maybe our problem is not AV itself but something else… I just put this machine xx.xx.xx.xx under a policy that has only AV enabled.

Hello @Sam Grayson and @Jim Kring, the IT departement tried to whitelist any folders but it didn't work finally. it was working few time if VIPM start before Cyberreason. Anyway IT solved the issue with puting my computer in a special group to only use antivirus of cyberreason. Now it works correctly. I try to get more information from IT departement and let you know when I have news.

For keeping track of used packages for our projects we'd like to put a list of used packages to our measuring data. That way we could later on see if a specific problem we encounter with our measurements might be due to the used packages. Is there an easy way for this? The best way I can think of right now is saving the names of installed packages out of VIPMs program data folder.

How to use VI Package Configurations (VIPC) – VIPM

Fantastic! Glad to hear you're up and running.

Thanks, that worked.

Release notes are written in the build specification. When, for example, developer realizes that some note should be added - package has to be rebuilt. But sometimes build of the package could take a lot of time (for example, build of our DBT toolkit takes approx. 1 hour with licensing, password protecting and further build). It would be great if there will be option to update just release notes, or another information which should not be compiled (authors list, etc.). That would help to save some time... But on the other side, developer should pay some more attention to build configurat

Building a VI package can take quite a while. For our Release Automation Tools, it takes about 20 minutes. Even though we build our packages on the build server now, it would be great to be able to feed back the progress of the build process to the CI system. As an example, the NI Application Builder API offers "progress bar" events, which you can register for and then show the progress details as you see fit: The VI Package Builder shows at least a few pieces of progress information in its status bar. Maybe these could be "routed" back to the VIPM API?

We use G-CLI to execute our CI tools, so we'd write back to G-CLI (and also to the front panel of the tool in case we run it manually). So the point would be to get the progress information back into the VI that's actually using the VIPM API. vipb.mov

I was able to reproduce the issue with the help of a colleague who has an RT Target. I've written up some info about this issue here: https://lavag.org/topic/21753-1d-array-to-string-not-compiling-correctly/ OpenG String v4.1.1.16 should fix this issue (although it's simply working around the LabVIEW compilation bug, which could potentially be causing other issues) I'm going to work to report this to NI, since we can reproduce the issue.

Ah, that's good to hear that IT was able to figure it out. Glad it's working for you now.

The trouble has been solved by IT. it was due to antivirus "cybereason" which was blocking .net for VIPM 2020. Thanks for your advices.

Hi @Jim Kring That worked😃. I had already gotten around the issue by uninstalling VIPM from Programs and Featuresafter having uninstalled it from NIPM.But then as soon as VIPM was reinstalled and updated again from its automatic update feature the issue in NIPM was back. As I suspected...The folder you sent was accepted as a source though so with that it is possible to do a repair without everything halting on the VIPM error. PS. NIPM is really terrible (compared to VIPM e.g.); From NIPM you cannot even repair VIPM without having to repair almost every component there is of Lab

This was on a machine with only one version of LabVIEW/RIO ever installed on it - 2020.

I suspect that the issue was that after installing VIPM as part of the LabVIEW installation I had applied an update to VIPM. NIPM offered me to uninstall VIPM, but I noticed that after uninstalling in NIPM (and NIPM reported that no VIPM was installed) I could still find VIPM under Programs and Features. Once I uninstalled it from there as well I was able to run the repair from NIPM. If this is the case the issue could perhaps reappear though, due to the VIPM update function....If NIPM is not directly involved it loses track of what is installed and from where...?

Currently at our company we are building internal toolkits which we use for projects, but do not put it to LVTN. Toolkits are published via OneDrive, everyone has mapped same local folder as repository in VI Package Manager. Different toolkits are handled by different developers. And sometimes there is a situation, when new version of toolkit is built, installed locally and tested, but it is not published to our local repository. It would be nice (I understand that on the other hand it is not such a common case) to have it in such a way, that: - developer installs new version of

Just the idea - not sure whether it is possible to implement. There are some packages, which are used as dependencies in other packages. And, we can find dependencies of the packages by sending package to configuration; but we can not find packages which are dependent on some particular packages. If we could do something like right click on the package in the list -> Find dependent packages, and it would show us list of packages (ideally even not installed) which use that package as dependency, that could be sometimes useful. Now, for example, we use some package as dependenc

Currently you have two options for Package Dependency version constraints: >= or == I propose VIPM should use or allow Semantic versioning. That way, if a dependency package has a breaking change, the dependent package can know that it is not compatible with the updated version. This is a big missing piece to VIPM's dependency management, since it currently assumes that a package will forever be able to support future versions of all dependencies, which simply is not the case in real life, as breaking changes do happen from time to time. Allowing for semantic versioning will help ident

You forgot one important thing: an asterisk "*" in the Machine Access List. Also, very important, verify your TCP port address in the VIPM (Options >> LabVIEW tab). If you have multiple LabVIEW installations make sure each VI Server have unique ports. Good Luck! Relativity1

I'd love to see these three License-related improvements to VIPM: 1) First, a main window column showing the package license, so it becomes very easy to see whether a package is open source, freeware, proprietary/custom, or something else. It'd be nice if the column title could be clicked to sort sort packages by license type: 2) To complement this, a change to the filter box with options to filter by license type, or maybe a second filtering box for this specific purpose. This would further help those searching for packages to focus on finding one they can afford and actually u