Software Deployment

Most sites I've worked at have used separate install and uninstall deployment "instances". The uninstalling instance uses the '/X' switch: msiexec /x program.msi /qMost sites would also include the logging switch in both instances:msiexec /i program.msi /q /l*v %temp%\whatever_install.log
msiexec /x program.msi /q /l*v %temp%\whatever_uninstall.log

ORIGINAL: robtk
How can I fix it so it will still remove older versions and install, but if the current version is installed, don't remove it?


use the upgrade table

Thanks for your quick reply.

I'm looking for a MSI script change that would be made for all our MSIs to change the "toggle" behavior.

Maybe use an AppSearch and LaunchCondition to detect the installed state, probably by reading the 'Uninstall' string from the registry?

Or adding an 'Abort Installation' CA with a suitable set of conditions to test whether you're installing, removing, repairing or upgrading?

Either course involves EVERY ONE of your MSIs. Surely it has to be easier to change the delivery mechanism!

ORIGINAL: robtk
Using this command line installs a program: msiexec /i program.msi /q
Running the same command line a second time will remove the program.

How is that possible? Is the package set to upgrade itself with the RemoveExistingProducts action set to run in the end? Erhm... ?

ORIGINAL: robtk

Using this command line installs a program: msiexec /i program.msi /q
Running the same command line a second time will remove the program. This is a problem. We use HP CA to distribute software and it has no idea if the program is already installed. How can I fix it so it will still remove older versions and install, but if the current version is installed, don't remove it?


To get around undesirable behavior in situations where I don't know if a target machine actually has an application already or not, I typically write a script for deployment (VB for me) with some logic that will bail out of the script if the product is found in the registry.

It's quite a bit faster than trying to embed additional functionality that may not be desirable in all situations into an MSI, and it also provides graceful, custom exit codes if you plan far enough ahead.


How is that possible? Is the package set to upgrade itself with the RemoveExistingProducts action set to run in the end? Erhm... ?

I was wondering this same thing. I've never actually seen that kind of behavior from an MSI, doesn't mean it's not possible though!

Wait a second...Are you now saying that this behaviour occurs with ONE of your MSIs?

The issue has been resolved. There was a CA to remove old versions and it wasn't checking if the currently installed version was current. Thanks for all your suggestions.