Archive: problems with Execwait coupled with checking for running while uninstalling...


problems with Execwait coupled with checking for running while uninstalling...
I have an installer that checks to see if the software is already installed and forces an uninstall before allowing a reinstall. To force the uninstall, I use ExecWait.

ExecWait '"$PATH_DIR" _?=$INSTDIR'

I also have a check in my uninstall that verifies the app isn't running when you uninstall by renaming the install directory, renaming it back and checking for errors.

If the rename fails, then the uninstall aborts because files are already in use.

The problem is that when the installer launches the uninstaller, forcing it to not copy to a temp directory so that it actually waits, the uninstaller is in use and the rename fails and doesn't allow the uninstall.

As a result, a user must uninstall "manually" before installing. So ultimately I have the desired effect but at the expense of end user confusion.

Can someone think of a better way around this?

I could check each individual file to see if it is in use (instead of renaming) but that causes problems of modifying my installer everytime a new file is created that needs to be uninstalled. This is the only workable, yet undesirable, solution I have thus far.

In the FAQ for ExecWait, I noticed this quote:

To get around this problem, the executed installer must be told to wait for the sub-installer or simply do the work itself.
This seems like an acceptable solution. My above implementation forces the installer to do the work itself (instead of copying itself to a temp dir and then running). I implemented it this way because I was told it is the only workaround that allows the installer to wait for an uninstall to complete before finishing.

How can I tell the installer to wait for the sub-installer instead?

Can you not just try a rename on the main application executable? Or, use a plug-in such as FindProcDLL or for a even more advanced check, with the LockedList plug-in.

Stu


if you copy the uninstaller to temp and execute it there in your installer(CopyFiles), the wait should work


Originally posted by Afrow UK
Can you not just try a rename on the main application executable? Or, use a plug-in such as FindProcDLL or for a even more advanced check, with the LockedList plug-in.

Stu
The problem is that it is an API that is being installed and literally hundreds of files (worst case) that would have to be checked individually (not just one exe). We could probably narrow it down to about 20 core files (exes, dlls, etc) but then it would become a nightmare to support the case where one of the others didn't get updated and is causing unexpected behavior.

I took a brief look at your LockedList plugin. Does that require the LockedList.dll to be distributed? If so, that is not an acceptable option. However, I also noticed that you include the source code for the DLL, is it ok to use that source in one of our existing DLLs (in terms of licensing)?

btw, this has kinda gotten away from the original question of "How can I tell the installer to wait for the sub-installer instead?" so if anyone has an answer to that, feel free to interupt this discussion.

-edited to add quote since new replys were in the thread

also noticed that you recommended a second plugin as well, I'll look at that one too and post in a new reply

Originally posted by Anders
if you copy the uninstaller to temp and execute it there in your installer(CopyFiles), the wait should work
So you are saying to simply manually copy it to a temp and then execute it the same way I did above (with _?=$TEMP_DIR instead of $INSTDIR)?

I think I tried that originally but ran into problems. I will have to check it out again and get post again. Do you know if that is what the WikiFAQ was referring to in the bolded section of the quote I have above?

Changing

ExecWait '"$PATH_DIR" _?=$INSTDIR'

to
CopyFiles "$INSTDIR\uninst.exe" "C:\Temp\"
ExecWait 'C:\Temp\uninst.exe _?=$INSTDIR'


Just need to add something to get the "real" temp directory and I'll be set.

Thanks everyone

$temp is real temp, but using $pluginsdir is probably even better (remember to call InitPluginsDir first if needed)


Now you've peaked my interest.

Why would $PluginsDir possibly be "better" than $Temp? Is it still be better considering I currently use no Plugins?


$pluginsdir a subfolder inside $temp(you don't have to worry about an existing file with the same name already in the users temp dir), and it is auto deleted just before the process exits


excellent, thanks again