NIPM fatal error

[GovBob]

 I tried to open NI Package Builder 32-bit today and I got a error dialog "NI Package Manager (NIPM) is not installed. This application requires NIPM to build packages, please verify that NIPM is properly installed. This application will close." I also tried as Administer and the 64-bit package as well. The NI applications were installed by IT around May of 2019. TestStand 2019, LabVIEW 2019 etc. I can't actually find NIPM per say but I'm pretty sure I used to have it on my machine. I do know my NI License Manager says that the Application Builder for LabVIEW 2019 SP1 is active (green). I'm pretty sure I used NIPM in the past because I had to install CVI. Is there a way to repair NIPM? I see that it can be downloaded from NI.com but I have no idea which version I should install? 

[Scott_Richardson]

There is no way to do a repair of NIPM, but installing a later version of NIPM will over right any installed portion of a previously installed version. The version of NIPM associated with 2019 software would have been 19.0.0. If you are using a Win 7 or 32-bit OS, you can install up to 20.6. NIPM version 20.7 will only install on Win 10 and 64-bit OS.

So you could try to install 19.0.0 and if that does not work, you could try to work your way up toward 20.6 without any potential negative consequences. Installing 20.7 or later on an OS will prevent TestStand and LabVIEW from building installers for Win 7, Win 8 and 32-bit OS.

[SteenSchmidt]

---

@Scott_Richardson wrote:

Installing 20.7 or later on an OS will prevent TestStand and LabVIEW from building installers for Win 7, Win 8 and 32-bit OS.

---

That’s a breaking change, why did that not result in a major version number change? Semantic (2.0) versioning is a huge benefit over year and any other scheme. For this exact reason.

Are different major versions of NIPM not side-by-side installable? If not, why not? That’s usually a given design parameter of modern software, one of the many benefits of assigning a version number scheme in the first place.

[Scott_Richardson]

Steen, I think if we could have incremented the major version of NIPM after 20.6 we would have, but I think our internal build processes limited us from doing so. You feedback on that is valid.

NI Package Manager's architecture cannot be side by side as it is responsible for managing all "NI" installed software, and older versions of NIPM typically do not know how to properly handle newer software that relies on capabilities in the newer NIPM. 

[GovBob]

Thanks for the information. This is really strange as I have packages located at C:\ProgramData\National Instruments\NI Package Manager\packages. I just can't find the executable. I tried the offline installer for 19.0 but the message said it was already installed? I'll keep digging.

[SteenSchmidt]

---

@Scott_Richardson wrote:

Steen, I think if we could have incremented the major version of NIPM after 20.6 we would have, but I think our internal build processes limited us from doing so. You feedback on that is valid.

NI Package Manager's architecture cannot be side by side as it is responsible for managing all "NI" installed software, and older versions of NIPM typically do not know how to properly handle newer software that relies on capabilities in the newer NIPM. 

---

Both TestStand and LabVIEW versions are side-by-side installable, while serving the same global operations. In TestStand's case you select an active version, and in LabVIEW's case it's the last manually opened version that is the active one. Other software solve it in other ways. For instance compilers are typical tools that have system limitations between major versions, but need to be side-by-side installable to support multiple diverse projects on the same dev computer, while still look as a single global service to the user (i.e. the OS or higher-level app automatically selects an appropriate compiler by context among the available options).

I agree it's harder to do, but for such a central and important component as a package manager, I'd go a long way to try to make this possible. I'm just pointing it out because there seems to be a large group of customer issues and questions originating from NIPM version conflicts. Especially forced upgrade that break backwards compatibility, and accidental upgrade that does the same.

[Scott_Richardson]

Steen, I think the side-by-side support is heavy solution than is likely required to support releasing NIPM without compatibility changes. NIPM's design of how we manage default directory paths, what we call NIPaths, is the biggest contributor to NI forcing newly released software to require a newer version of NIPM to install it. Our current design requires NIPM to know about these NIPaths for new software so that NIPM can support installing the new software to non-default locations base on registry key values and pre-creating the folder. If and when we can decouple this from NIPM releases, NIPM could decrease the impact of version compatibility.

[cbutcher]

Scott, I think that the version of NIPM required to install a package depends generally on the software installed on the machine that makes the package (i.e. updating NIPM on one machine used to build packages necessitates an update on all machines that install them).

I say generally because I know that it is possible to create the control file manually and then pack the package, which if I recall correctly allows a much freer choice of older package (manager) version. (seems to be true, reading one of your other posts here: CompatabilityVersion in control file - as an aside, thank you for the clear description there).

If the largest driver of incrementing that value is the NIPaths dictionary, could a lower value be set for packages automatically based on the earliest version of NIPM that would be capable of correctly packaging/installing the package? (i.e. calculated from the paths that were actually used?)

Edit: I see reading the penultimate post in the above-linked thread that that was already requested by the OP there.

[Scott_Richardson]

Potentially. Another trigger for requiring a higher compatibility version is if the package uses feature that are only understood by a higher version of NIPM. Unfortunately, implementing a technically solution to address both of these is not small.