04-18-2023 04:08 PM
Previously, you could install a newer version of NI Package Manager so that you could install newer packages if needed. If, for example, you needed to install LabVIEW 2022 Q3, you could install the latest version of Package Manager, install LabVIEW, then uninstall NI Packager Manager and install the version your company uses (in our case 21.3). This has worked consistently until NI Package Manager 2023 Q2. Now if you install 2023 Q2, uninstall it, then go to install an old version of NI Package Manager. The install windows says you have to uninstall everything first, in order to then install NI Packager Manager. This includes things like LabVIEW 2019, TestStand 2017, TestStand 2019, etc... If I go to install NIPM 21.3 (even 2023 Q1), after having installed 2023 Q2 (without installing anything else), I have to uninstall my whole system to get on the older version.
Is this due to the .NET Framework change? Or is there a way around this so NI Package Manager will just install without trying to uninstall everything first.
Solved! Go to Solution.
04-19-2023 02:16 PM
Slade, Yes, the reason that your workflow is triggering the uninstall of a lot of NI software is related to NIPM now installing .NET 4.8. NIPM 23.3 now has an explicit dependency on .NET 4.8. The .NET 4.8 package has a conflict with older versions of NIPM because there are technical reasons that we had to include that conflict relationship. When installing the older NIPM that conflicts with the installed .NET package, uninstalling the .NET package will uninstall anything that depends on it, which is a lot of NI software.
FWIW, if you install NI software using an "online" installer, the installation operation will always install the latest released version of NIPM because the online installer pulls from NIPM's mono-feed on ni.com. If you are installing NI software using offline installers, the installation will install the minimum version of NIPM required to install the software. So depending on what you are installing using offline installers, you might not need to perform your "downgrade workflow".
Your downgrade workflow of uninstalling NIPM and reinstalling an older version of NIPM is not officially supported because doing this can get your system into a bad state for NIPM. Once in this downgraded state, there could be cases where NIPM might prevent future uninstall/install operations from working, and another concern is that any package build related operations performed in the newer version of LabVIEW might error when built or installed because the require version of NIPM might be too low.
If you still want to use a downgrade workflow, you should be able to use the NIPM CLI to do this with a single command. For example, to downgrade NIPM to 21.3, use the following command while connected to ni.com:
nipkg install ni-package-manager=21.3.0.49256 ni-package-manager-upgrader=21.3.0.49256 ni-package-manager-released-feed=21.3.0.49256 system-windows-x64=21.3.0.49256 ni-package-manager-deployment-support=21.3.0.49256 --allow-downgrade --accept-eulas --force-locked
All the required packages for NIPM are included in the mono-feed that NIPM registers when installed with the name of ni-package-manager-released.
If you want a different version, you can call nipkg list ni-package-* and nipkg list system* to get the precise package names with version suffixes.
If your target computer is offline from ni.com, you would have to create a local feed with all the require package by using the below commands on a connected system, and then register the feed on the offline target system before using the above install command.
"C:\Program Files\National Instruments\NI Package Manager\nipkg.exe" download --all-deps ni-package-manager=21.3.0.49256 ni-package-manager-upgrader=21.3.0.49256 ni-package-manager-released-feed=21.3.0.49256 system-windows-x64=21.3.0.49256 ni-package-manager-deployment-support=21.3.0.49256
"C:\Program Files\National Instruments\NI Package Manager\nipkg.exe" feed-create ./ ./
Hope the above helps.
04-19-2023 05:42 PM
Thanks Scott, that helps a lot.
I realize our process is not ideal. But it's one of our workarounds for the Control File CompatabilityVersion when trying to install on systems we can't update NIPM on. Although I have other workarounds I'm developing that will make it so we don't have to downgrade our developer computers to get around that. They just aren't ready for primetime, so still have to downgrade for now.