WinZip 11.1 and the AreExeFilesLocked CA
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!?
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
[ + ] Show comments
Answers (3)
Please log in to answer
Posted by:
bkelly
17 years ago
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!
Posted by:
anonymous_9363
17 years ago
Posted by:
AngelD
17 years ago
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.