Software Deployment

Well, you got some options on this matter. You can either:

* Use upgrade codes. For instance, if you know the GUID of your "old" application, add this in your package (what repackaging software are you using by the way..?) so the "new" package knows it's an update of the older version and removes it for you;

* Using the software deployment tool, using either commandline (msiexec /x {GUID}) and, for instance, when using SMS as the deployment tool, making sure this runs before the installation runs, or, create an uninstall script in for instance VB script (a lot of people on Appdeploy tend to use vb script) to uninstall the "old" app, or create one vb script to uninstall and after that install the new app. I usually create a vb script to firstly uninstall the app, then install the new app.. If the uninstall is dodge (what *does* happen sometimes) vb script is relatively easy to fix the damage done by uninstalling.

Option 1 is available to you no matter what repackaging software you use, option 2 depends on what system you use for software deployment..

Yes, and don't try to use a custom action (nested MSI type) because it won't work silently.

Hi turbokitty,
what do you mean with 'won't work silently'?
if you call msiexec /qn, it will work silently, but you can call it only on certain stages in the main MSI.
Regards, Nick

It is my understanding that you can't call it as a deferred custom action and therefore the uninstall can't be cancelled in the event of an installation failure.

Hi folks,
to much guessing about this, i think.
First: Premnath, please specify, what you are exactly trying to achieve (just uninstall an second MSI with no relation to the first or create a real nested install).

Second: turbokitty, you're right about a plain CA call to msiexec /x {GUID} /qn, that is only working in the 'InstallUISequence' or after 'InstallFinalize' in the 'InstallExecuteSequence'.
But a real nested CA is called deferred and does not have this caveats.

Regards, Nick

nheim, are you sure about that? Even a deferred custom action must call the windows installer service when run silently.. and the service would be busy with the current MSI so the nested call would bomb.

Hi turbokitty,
yes im sure about this because i've done it myself for few times in very special situations.
Several instances of msiexec can reside in memory, but they have to be called the 'right way' (like from a CA-DLL or a nested CA).
Please read this: http://msdn2.microsoft.com/en-us/library/aa368010.aspx
Regards, Nick

Interesting article. I've never read that one in particular.

Like I said, I've never been able to get this to work with any reliablity, even with a nested CA. The article does recommend not doing this, but I've broken a few rules in my day.. so I could see why someone might give it a go.

I prefer to control the state of the machine with a deployment tool as this will allow you to track failed installations/uninstallations and provide reporting functionality.