10-13-2021 11:48 AM
Is there a way to suppress the top banner message about NI Package Manager updates? Also is it possible to filter out the NIPM updates from UPDATES tab as well? We are having issues due to people having different versions of NIPM and that causing packages to to be listed in the PACKAGES tab if they build with a newer version the default version of the team.
Solved! Go to Solution.
10-14-2021 01:15 PM
You can suppress the banner by running the following command from your NIPM installation directory (usually C:\Program Files\National Instruments\NI Package Manager): nipkg.exe remove --force-essential --force-locked ni-package-manager-released-feed. This unregisters the NIPM update feed. Unregistering the feed should also remove the NIPM updates from the Updates tab.
Note that if you upgrade NIPM by other means (perhaps by downloading the installer from the NIPM downloads page), the feed will be registered once again, and the banner will return when updates are available.
10-14-2021 02:14 PM
Only caveat is that removing the feed will not suppress the too old message if it is present. However, it will render it unable to complete if clicked.
10-15-2021 09:09 AM
To add context, the reason this is being seen is the installed package compatibility issue mentioned in the Downgrade thread.
10-15-2021 01:04 PM - edited 10-15-2021 01:05 PM
Related to that "too old to handle newer installed software" message, I discussed this with the development team earlier this morning, and we agreed that we should probably have a feature to support suppressing NIPM update functionality. That would prevent both the "too old" and "update NIPM" banners from displaying. We had gotten a request for something like that from an internal team earlier this year as well. I can't speak to when that feature will be prioritized, but we appreciate your engagement here, and it's on our backlog.
10-16-2021 04:19 PM
Hi Bill, so that I can capture specific rationale for the ask, can you summarize why you or your end-users need the ability to prevent systems from updating NIPM?
10-18-2021 09:39 AM
The main reason is for consistency/uniformity. It is basically me supporting ~100 user so I am trying to keep things simple. Also, we have run into issues when someone has updated NIPM that their packages are not shown in the NIPM GUI of others who are not. The issue seems to be the version of NIPM installed on the machine building a package, not listing the minimum feature set required.
10-18-2021 12:53 PM
Bill, thanks. Restricting PM version would be the best option right now. A related consideration that we have is to improve PM internals so that PM does not have to increment its compatibility version almost every release.
12-22-2021 08:27 AM - edited 12-22-2021 08:28 AM
We have customers facing the same issue for similar reasons.
I our case we have a group of test developers sitting at there developer PC's creating NIP's for deploying custom step types etc. for test stations running TestStand.
The developers are online and can get the latest NIPM when ever they want. However the test stations are at an EMS in the fare east running in an offline environment. We need to make sure that the developers and the test stations are always using the same version of the NIPM due to the compatibility issues from version to version. Right now the best way to ensure this is to prohibit the developers from updating the NIPM when ever a new version is available, and do the updates in a more controlled way.
On a side note, I do not understand the versioning scheme of the NIPM. Why can there be breaking changes in a non major version release? That makes no sense. It would be like making breaking changes in a LabVIEW service pack.
12-23-2021 11:31 AM
Hi JC -
NI software relies on an internal feature that we call NI-Paths, which allows a product like LabVIEW, to define specific paths so that it and other products can query it. Examples include where is LabVIEW installed, where is NI's default program files directory, where is vilib. If a new product or a new side-by-side version of a product needs to define a NIPath, that path must be available to all software and known to both our old legacy installer technology and to NIPM. If a product requires NIPM to know that path and that version of NIPM is not installed then the software cannot be installed. We currently use the compatibility version of NIPM to enforce that, and so we must increment that compatibility version when a new NIPath is added.
We have some backlog work to investigate decoupling NIPaths from the NIPM compatibility version and if implemented would lessen how often the compatibility version might be incremented, but would not prevent it.