3 replies to this topic

[KathyMorey]

I am not at all sure that the request I have received is possible to do with an MSI. If anyone can advise me how to accomplish this, or can tell me unequivocally that it cannot be done, I would very much appreciate it!

We have customers who want to deploy our client through ADS, so we are going to rewrite it from an InstallScript MSI to a Basic MSI as a major upgrade.

The dilemna comes in with uninstalling the previous, InstallScript MSI versions. I wrote a CA to execute a C++ dll that runs right before ExecuteAction in the UI Sequence. The .dll uses CreateProcess() to run idriver.exe with the appropriate .iss file (from support files) to uninstall previous versions, then it ends and the MSI continues to the Execute Sequence to install the new version.

Because ADS runs installs silently, though, the uninstall gets skipped if you deploy the package through ADS. My boss wants me to do the following:

1. At the beginning of the ExecuteSequence, check for the previous versions.
2. If detected, start a C++ executable and abort the install.
3. Use the executable to uninstall the previous versions.
4. Have the executable start the MSI back up to run a normal, silent install.

I'm not sure how I would go about ending the MSI gracefully from the Execute Sequence. I also don't know if I can execute a C++ program from the Execute Sequence if the install is running through ADS (i.e., what is the operating system status at the point ADS installs are run?)

Finally, I don't know if I can programatically start an MSI from an executable that was started during the ADS install process (again, what is the status of the operating system at that point?)

If anyone can help me, I would be extremely greatful! Thanks

Edited by KathyMorey, 29 March 2006 - 21:53.

[Glytzhkof]

Large companies generally have processes in place to handle upgrade scenarios. As such it is much more important to convert your setup to basic MSI (should be called REAL MSI) than to have the automatic uninstall of previous version work correctly. If I were you I would use the upgrade table to detect the existing install and then just exit the new setup if the old version is found writing to the log that the older version has to be removed first.

There are so many issues with deployment through distribution systems that I would not write any "smart solutions" like the above to fix it. It might seem to be elegant but it will just cause more problems. I know managers are hard to convince on issues such as these since they simply have no knowledge of large scale deployment details, but the best you can do is to provide a good basic MSI that will work properly for future versions and upgrade scenarios.

[Stefan Krueger]

I don't think this will work. Typically AD will be used to push software to locked down desktops, i.e. the user doesn't have administrator rights. The pushed setup can install with elevated rights when pushed via AD, but only for the script execution phase, i.e. for deferred actions between InstallInitialize and InstallFinalize.
Since your custom action exe would be launched before InstallInitialize it would not run with elevated permissions, and thus the MSI file it will essentially launch will not run with elevated rights and thereofre fail.

Also: Since the final installation would be launched from your exe, and not from AD, it would not be managed by AD. AD would only see that the first MSI has been cancelled (by your custom action), so the application would appears as being not installed.

And I have to fully agree with Glytzhkof. I suggest they uninstall the old version (InstallScript MSI) in the same way they installed it in the first place.

[KathyMorey]

Thank you both for your comments!