Archive: UninstallDir


UninstallDir
Hi

Seems that bug has not been noticed yet.

When using WriteUninstaller, the uninstaller can be created in any place. The problem is that the unnstall path used during unsinatll is based on the path of the uninstaller.
So, if my uninstaller is copied to win directory, i won't be able to uninstall anything because INSTDIR will be initialized with a wrong value..

One solution would be to be abe to use a command like UninstallDirRegKey ;)

Regards

Julien


How about writing the $INSTDIR of the installer to the registry, and then in the uninstaller, simply read the $INSTDIR from the registry.

-Stu


It's not a bug, it's by design and it is known.


Hi kichik,

I'm using NSIS 2.02 and I noticed this behaviour is still occuring.

From my perspective, it would make sense for the uninstaller to use the "true" value of $INSTDIR as defined in the installer. I believe the uninstaller should work regardless of which directory it resides in, the same way the installer works regardless of what directory it resides in when it is executed.

Consider the case of a user manually moving (by accident or on purpose) the uninstaller to a different directory. By having the uninstaller use the "true" value of $INSTDIR as defined in the installer, the uninstaller will continue to operate correctly.

Furthermore, in the case when WriteUninstaller doesn't place the uninstaller in the installer's $INSTDIR directory, I don't believe the uninstaller should have to rely on workarounds such as reading an "InstallLocation" value hidden in the registry or in an .INI file, both of which could be deleted, leaving the uninstaller effectively crippled because it is not located in the "correct" directory.

You mentioned this behaviour is by design. To let me understand your point of view, could you please explain your reasoning why you think the uninstaller should behave this way by design?

Thanks!

Shayne


It behaves this way so it'll be self contained by default and won't write anything, anywhere. And lets not forget the cool fact that it allows you to move the entire installation directory without having to reinstall.


Thanks for your reply! Okay, I can see your point.

Now my rebuttal. And then I shall let the issue rest.

Consider the following case. Someone writes an installer that puts the software in $PROGRAMFILES and the uninstaller in $WINDIR (like Firefox, for example). This person, unaware of the behaviour of $INSTDIR in the uninstaller, wrote the following code.


InstallDir "$PROGRAMFILES\MyApp"

Section
CreateDirectory "$INSTDIR"
File "MyApp.exe"
WriteUninstaller "$WINDIR\Uninst.exe"
SectionEnd

Section Uninstall
RMDir /r "$INSTDIR"
Delete "$WINDIR\Uninst.exe"
SectionEnd


Thinking $INSTDIR refers to the location in $PROGRAMFILES, the person believes the uninstaller will delete the software. But instead most of their OS gets killed. (Of course, using "RMDir /r" at any time is a risky game and should be avoided.)

At the very least, I'd recommend adding to the documentation a note about the $INSTDIR behaviour in the uninstaller.

Thanks again!

Lots of bad things can happen if you misuse any command, even Goto.

I have added more information about it to the documentation.


Especially Goto! :D


Goto is very destructive. For example, this one will most certainly crash the installer:

OutFile bla.exe
Name bla
Section
Goto +1000
SectionEnd
This one will cause an infinte loop (the message box is there just so you can stop if you try it):
Name bla
OutFile bla.exe

Function test
Goto +2
FunctionEnd

Section
MessageBox MB_YESNO "stop?" IDYES stop
Call test
stop:
SectionEnd
And last but not least, this will erase all of the files in C:\Program Files (if you remove the comment from RMDir /R, of course):
Name bla
OutFile bla.exe

Function test
Pop $0
StrCmp $0 bla +5
MessageBox MB_OK "didn't push bla"
# some commands that someone
# commented. unfortunately, he/she
# forgot to update the jump
FunctionEnd

Section
Push bla
Call test
MessageBox MB_OK "RMDir /R $$PROGRAMFILES"
#RMDir /R $PROGRAMFILES
SectionEnd