Nothing but confusion about building and using packages

[altenbach]

Sorry, I have a hard time understanding how to built and use packages.

Scenario:

1. Until now, I build classic installers in LabVIEW 2015. Always worked fine.
2. I branched the project and did a LabVIEW 2019 branch for testing.
3. Decided to try out building and installing it as a package. Separate install location for the 2015 version, etc.
4. Package test Install went fine.
5. OK, so how do I uninstall this thing now???? Tried:
   
   1. Windows 10 start menu, right-click app icon...uninstall. Just opens windows control panel and new install is nowhere to be seen.
   2. Open package manager ... all I see is the old 2015 version. Nothing about the new 2019 version.
   3. double-click package again: Message: "Package is already installed, No operation will be performed"
   4. Again: How do I uninstall thins thing!!!????

Thanks!

[altenbach]

Ah, OK. It actually is in the NIPM under "installed" if I uncheck "products only". The old version shows even if "products only is checked", i.e. at the default. I guess I don't know the definition of product. 😉

(Hey, there is even a package building checkbox to show it when "products" is selected. Why is it not checked by default?)

[altenbach]

I guess I start liking the package method (:D), so I have a few questions:

1. If I ultimately decide to transition to the package install method for all my users, is there an easy way to detect and automatically force uninstall of the old 2015 non-package version of the same software. I know the upgrade code, for example.
2. I have a built script that modifies setup.ini to skip the "fast startup" question. Can I do something similar when building a package? (My code is pure analysis software and does not interact with any hardware. I don't want to distract users with unnecessary questions).
3. If I only distribute a package (not a package installer), how do I instruct users to use it on a clean computer that has nothing on it. Do they need a NI profile to install NIPM? (See also)
4. Similarly, What are the instructions if they want to uninstall it again?
5. How many things can go wrong if they don't follow instructions? (I know my users! :D)
6. ...

[APena]

Hi altenbach,

Regarding number 1, technically yes you can force the uninstall of a LabVIEW 2015-built distribution through the installation of a package by using a Conflicts relationship specifying the upgrade code. For example:

Conflicts: 5581b2cc-fdfc-4084-9a02-7e453276dda7

At install time of the new package, you will see a screen similar to the one below indicating that the old software will be removed if you proceed:

However, as far as I'm aware, none of the package builders (e.g. LabVIEW Application Builder package build spec, NI Package Builder) currently expose this specific relationship through their UI. So if you want to do this, you will need to modify the control file manually and then pack the package manually via the NIPM CLI. Perhaps one way to do this more easily and possibly programmatically would be to build the package in LabVIEW, then use the NIPM CLI to unpack the package, modify the control file, and then repack the package via the NIPM CLI again.

Regarding number 2, I think technically there should be a way to do this, but as I was trying to test this out before posting this I wasn't able to get it to work. I'm going to keep working on it and asking around and will post back if/when I find out more.

Regarding number 3, if you choose not to build a package installer, then your end-user will need to acquire and install NI Package Manager separately. They can download it from ni.com (https://www.ni.com/en-us/support/downloads/software-products/download.package-manager.html#306124) and I don't believe it requires an NI User Account (it didn't prompt me to log in when I just tried).

Regarding number 4, are you referring to uninstalling NI Package Manager or the package(s) that you give them?

Regarding number 5, hmm... 42?

[altenbach]

---

@APena wrote:

Regarding number 4, are you referring to uninstalling NI Package Manager or the package(s) that you give them?

---

Thanks for you comments!

I guess my problem is related to my first post (Not following any instructions (point 5 :D), but following typical procedures).

Let's assume they don't have any existing NI software and want to uninstall whatever they put on minutes earlier because they don't like me or my programs.

The start menu has an "uninstall" right-click item added by windows 10, so most might start there. Clicking this opens the software control panel and my app is nowhere to be seen and nothing happens. They might think that NIPM relates to it and uninstall that instead (Yes, there will be warnings, but if they ignore them, my software will probably be stuck there forever. ;D!)

Maybe this is something that could be better implemented in windows 10 such that if I click "uninstall", NIPM would open instead. Not sure if that's even possible.

I guess they would need to open NIPM, uninstall everything, them uninstall NIPM as a last step.

I'll probably skip the step 1 discussion and have them uninstall the old version or keep both, making sure there are no naming conflicts.

[JoshuaP]

I haven't tried this, but I was wondering if you could use a custom action to manually add your own option to Add\Remove software and set the UninstallString to use the nipkg.exe command-line to uninstall your package.

https://nsis.sourceforge.io/Add_uninstall_information_to_Add/Remove_Programs

[Romain.P]

---

@APena  a écrit :

Regarding number 1, technically yes you can force the uninstall of a LabVIEW 2015-built distribution through the installation of a package by using a Conflicts relationship specifying the upgrade code. For example:

Conflicts: 5581b2cc-fdfc-4084-9a02-7e453276dda7

At install time of the new package, you will see a screen similar to the one below indicating that the old software will be removed if you proceed:

---

Hello,

This is exactly the function I need. I managed to build (with NIPM CLI) a new package with "conflicts" and "replaces" relationships to an older non-package software.
But the package still doesn't detect the older software. I don't see anything like your screenshot.
I tried the product code and the upgrade code of the older software.

Are you sure that NIPM supports product/upgrade codes? I see only package names in relationship examples.

[WesW]

Yes, you should be able to do this in NIPM, and is actually how NI has authored its own NIPM packages to upgrade anything from the old installer technology. What happens behind the scenes is that NIPM knows how to discover all of these old installers once installed, and reports them as if they were installed as packages. It does this by mapping the MSI properties to NIPM attributes. So, the original MSI's UpgradeCode, ProductVersion, and ProductName becomes the NIPM Package name, Version, and DisplayName, respectively.

Here's a suggested procedure how to use this to create a seamless upgrade:

1. Install NIPM and also the LV 2015-built distribution you're wanting to upgrade.
2. Run this NIPM CLI command: nipkg.exe info-installed > %temp%\ii.txt
   (This command reports the attributes for all installed packages. This should include your LV 2015 installer, because of the mapping logic I described above.)
3. Search ii.txt for the ProductName of your LV 2015 built installer, and you should find it in the DisplayName: attribute. 
4. Once you found that section, look for the Package: and Version: attributes - this is the package name and package version that NIPM will always report for your old installer. This package name will be a GUID, and it is case sensitive. For example:
   Package: ab3599b6-97d9-4fe7-9e0d-87528ab8e8a7
   Version: 5.60.49152
5. Now in your new NIPM package, declare a Conflicts and Replaces against the Package and Version you found in the previous step (your old package). For example, if I was want my new package upgrade the old installer in the previous step, I would add:
   Conflicts: ab3599b6-97d9-4fe7-9e0d-87528ab8e8a7 (<=5.60.49152)
   Replaces: ab3599b6-97d9-4fe7-9e0d-87528ab8e8a7(<=5.60.49152)

That last step might need some explanation. Using Conflicts\Replaces together is a "recipe" that says that if you find a matching package name and version, then have this new package be treated as an upgrade of what matches. So, this will allow the package to upgrade the old pre-package installer.

[bienieck]

---

@APena wrote:

Regarding number 2, I think technically there should be a way to do this, but as I was trying to test this out before posting this I wasn't able to get it to work. I'm going to keep working on it and asking around and will post back if/when I find out more.

---

Hello Aaron,

Do you have any updates regarding this? Can I somehow deal with this using nipkg.exe install command.?