8 replies to this topic

[garyflet]

We are transitioning from using Wise install to Installshield basic MSI. I have set up my Installshield install to detect if an old Wise install is still on the machine, and if so, to run the Wise uninstall to delete it. Then it continues to install the lastest files. The trouble is that then the Installshield uninstall doesn't work properly. Registry entries and the files in the install directory are not uninstalled.

However, if I uninstall the Wise install first, then install with the Installshield install, and later uninstall, it works fine. Any ideas on how to go about fixing this would be greatly appreciated .

[Stefan Krueger]

How are you launching the Wise uninstall and when in the sequence?
Is it a Wise Script install or a MSI install crteated with Wise?

[garyflet]

Thanks for your reply! I launch the WISE uninstall immediately after the InstallInitialize with a custom action. If I position the custom action immediately after the CostFinalize (because whether I launch or not depends on a variable which indicates whether the Wise uninstall is there and the user has OK'd the uninstall) the message appears during installation:

"Error 2762. Cannot write script record. Transaction not started."

And then the installation is aborted. So I assume that the earliest in the sequence that I can put my custom action is after the InstallInitialize.

Thanks again,
Gary

[garyflet]

I changed my custom action to "Immediate Execution" from "Deferred Execution". Now if I put my custom action prior to CostFinalize and after setAllUsersProfile2K I get an error message during the install:

[Stefan Krueger]

Deferred custom actions must be placed between InstallInitialize and InstallFinalize, so an immediate action mioght be better - however, depending on the UAC settings in your project, your setup might not have full admin privileges in an immediate action.
Directory properties get resolved during CostFinalize, but maybe you could use an environment variable instead: [%ProgramFiles] should work.

I guess the problem is reference couting. If CostFinalize detects that the files already exist it assumes they are used by another application and therefore doesn't remove them during uninstall.
Some options I can think of:
- Use a launcher exe to first uninstall the Wise setup and then start the new msi setup.
- Decrement the SharedDllRefcount registry entries in your msi setup.

[garyflet]

Thanks once again for an insightful reply. In the custom action for the uninstall, I put ProgramFilesFolder as the “Working Directory” just to put something there. The install finds the complete path to the WISE uninstall in the registry, entered as “Filename & command line”. I tried [%ProgramFiles] (as well as [%ProgramFiles%] and[ProgramFiles]). I got the message “The directory entry '[%ProgramFiles]' does not exist in Directory table”. Then I tried leaving “Working Directory” blank. I have the complete file path for the WISE uninstall in “Filename & command line”, having picked it up from the registry. With this configuration, however, the WISE uninstall never ran, it seems the custom action wasn’t executed. So maybe there’s no way to do it before CostFinalize since there’s nothing in the Directory Table, and the InstallShield uninstall doesn’t work after it.

I probably don’t understand your launcher exe solution. I would create my own executable that would detect the WISE installation, run the WISE uninstall, and then run the InstallShield install. But how would I uninstall my launcher? Or maybe you mean an InstallShield install that deals with the WISE uninstall first, and then runs my current InstallShield install? Then I'm not sure how the launcher is different from my custom action.

I’m sure I don’t understand your other solution, decrementing the SharedDllRefcount in the msi file. Is that done in the InstallShield IDE? I’m using the compressed version. I've noticed that when the InstallShield uninstall doesn't work, it doesn't uninstall registry data under HKEY_LOCAL_MACHINE->SOFTWARE->Microsoft->Windows->CurrentVersion->SharedDlls.

Thanks again...

[Stefan Krueger]

Try changing the custom action type from 34 (EXE file having a path referencing a directory) to 50 (EXE file having a path specified by a property value).

The launcher would be a setup.exe, so it doesn't get installed, but it's shipped on your CD or downloaded from the web. You can put it in a self extracting exe wrapper that also contains your setup, so it gets extracted to the temp folder.

Decrementing the value in HKEY_LOCAL_MACHINE->SOFTWARE->Microsoft->Windows->CurrentVersion->SharedDlls would have to be done in a custom action that reads the value, subtracts 1 and write the result back to the registry. You could write this in InstallScript.

[garyflet]

I changed my custom action to "stored in the Property Table" but for some reason it never executed (the WISE uninstall never got going) before or after CostFinalize. Even when I made two new strings, which I then stored in properties: the first property being the path to the executable (Executable Property), the second being the path to the a file needed in the command line. As a sanity check, I found that the old type custom action did indeed execute (run the WISE uninstall). In all these cases the setting was "immediate execution."

At any rate, my boss has decided I'm spending too much time trying to uninstall WISE from within the InstallShield install, so now when the install detects the presence of WISE, a message box appears stating that the user must uninstall the WISE install prior to installing the new install.

Thanks very much for your help. Although I'm not going to use any of your solutions, I learned a lot along the way. Much appreciation! You're a gentleman and a scholar.

Gary

[Stefan Krueger]

Sorry it didn't work. A log file should tell you if the installer actually tries to launch your custom action (and maybe fails), or doesn't even try (maybe because the condition evaluates to false).