Here is an interesting approach how the WinZip package is trying to look for files in-use to prevent a successful install/repair/uninstall.

If you install WinZip as per-machine and then trigger a repair as a non-admin user the custom action AreExeFilesLocked is executed (always, no condition) to check for any running winzip related process. The repair fails with the following error message:
The WinZip component 'C:\Program Files\WinZip\winzip32.exe' is running, possibly in another user session. Please logout all other users and press the Retry button to continue, or press Cancel to abort the installation.
(We didn't want to abort the installation did we and there are no other users currently logged in to logout so hitting the Retry button multiple times won't do any good.)

There is no process with that name running.
Heck, I havn't even launched winzip yet since installing it!

The problem is that this custom action (AreExeFilesLocked) itself is locking this executable (winzip32.exe) as it has an open handle on it and therefore prevents a repair from occuring successfully.

Preventing the CA from being executed during a repair (ex. by adding a condition as NOT REINSTALL) or just preventing it from being executed at all; condition to resolve to false (ex. 1=0) or remove the CA from the InstallExecuteSequence table and the repair is a success.
This time any running winzip process will also be closed automatically to perform the repair without any files in-use.

What were they think about!?
0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


Goes to show there are still a lot of people who don't understand MSI as well as they should. A product as widely used [installed] as WinZip should really have the attention of someone who understands this kind of problem. Even worse-- like we who create packages for internal distribution, these kind of things should be identified during testing!
Answered 11/19/2007 by: bkelly
Red Belt

Please log in to comment
What were they think about!?There's your mistake, Kim - you imagine that vendors think :)
Answered 11/19/2007 by: VBScab
Red Belt

Please log in to comment
Just a little correction.
prevent a successful install/repair/uninstall.
It should be "prevent a successful repair." as during install and uninstall this is performed under an admin/system context depending on the deployment solution.

We sure hope anyway [:D]
Answered 11/19/2007 by: AngelD
Red Belt

Please log in to comment