Separate uninstall shortucts for each component

I have a situation where I would like to be able to have separate uninstaller shortcuts in add/remove programs for each component in my application (yes this is my preferred way as opposed to a component page in the uninstaller for reasons too lengthy to describe). I had a theory as to what I could do: In each section I would write an uninstaller (using WriteUninstaller) and then add a separate registry key for each component in the Windows uninstall section so that an icon would show up for each one in the add/remove programs list. This works great. As a note, I also have uninstaller sections that are specific to each component as mentioned in other posts (e.g. section named "mySection" has uninstaller section "un.mySection"), but that is sort of trivial in regards to my problem.

I then thought I could simply check the processes and search for the name of the uninstaller executable that is running and determine what needs to be uninstalled based on that. Unfortunately, no matter which one of the uninstall shortcuts is clicked, it shows up in the processes list as "Au_.exe*32". This means I can't differentiate which of the uninstall executables was clicked and throws my whole theory out the window. Does anyone have any thoughts on how I could have a separate uninstall shortcut for each component? I have little hope this is possible (or at least straightforward), but a man can dream I guess. Thanks in advance.

If I were going to do what you describe, I'd create separate installers (by writing and compiling other scripts) for each component, then I'd include those uninstallers in the main installer.

Each uninstaller would know only about it's one component; each component entry in the Add/Remove program registry key would point to the correct uninstaller for that component. When the user goes to remove that component, it calls 'that' uninstaller, which removes the correct component (and that item from Add/Remove program registry).

Don

What about using the command line? Add a switch in the UninstallString path to tell the uninstaller which component to uninstall.

Use FileFunc.nsh with GetParameters+GetOptions (see NSIS manual).

Stu

Thank you for the responses, they both sound like good ideas. I will look into each one and see which best fits my needs. Thanks again.

Creating another installer and uninstaller script would be definitely be a bit more work.

All you need in your uninstaller is this:

${GetParameters} $R0

${GetOptions} $R0 `/product=` $R0

${If} $R0 == `product 1`

  # do product 1 uninstall

${Else}

  # do product 2 uninstall

${EndIf}

Stu

Actually, you might want to make that:

${GetParameters} $R0

${GetOptions} $R0 `/product=` $R0

${If} $R0 == `product 1`

  # do product 1 uninstall

${ElseIf} $R0 == `product 2`

  # do product 2 uninstall

${Else}

  # display error

${EndIf}

I ended up using almost exactly the code that AfrowUK (with MSG's error portion) and it worked great! Thanks again for the help, I am still a noob to installers in general so I appreciate the patience for what may seem like a simple problem. For those interested, here is how I added the '/product=' option to the uninstallString:

WriteRegStr ${PRODUCT_UNINST_ROOT_KEY} "${PRODUCT_UNINST_KEY}" "UninstallString" "$\"$INSTDIR\Uninstall product.exe$\" /product=aProduct"

Uninstaller Issue

${GetParameters}

Im new to NSIS installer. Im also facing the above issue. It will be very helpful to me if can explain in detail.

MY Issue :
-----------

Im having two components (viz. Client and Server ) in my installer with separate directory path .

As u have said the reg key for UninstallString has been set but im unable to get the parameter while uninstalling.

One more thing i would like to know is if i install client and server separateky I will have a two uninstaller which i created by the below code



WriteUninstaller "$b1\ClientUninstaller.exe"
WriteUninstaller "$b1\ServerUninstaller.exe"

How will the software recognize which uninstaller has been triggered.

Should i pass parameters in WriteUninstaller ???

Originally Posted by Pravin View Post

How will the software recognize which uninstaller has been triggered.

Grab the uninstaller filename from $EXEPATH, or add parameters through the uninstall shortcut, or use uninstaller sections, or use FileWriteByte to append specific data to each uninstall.exe.

Thanks for ur response MSG.

1.As u said i tried using $EXEPATH . As already discussed by blh83 no matter which one of the uninstall shortcuts is clicked, it shows up in the processes list as "Au_.exe*32".

2.Next i tried by passing parameters .

I dont know where i need to pass the parameters

whether in WriteRegStr ${PRODUCT_UNINST_ROOT_KEY} "${PRODUCT_UNINST_KEY}" "UninstallString" "$\"$INSTDIR\Uninstall product.exe$\" /product=aProduct

or

WriteUninstaller "$b1\ClientUninstaller.exe

can u guide me in a detailed manner. Thanks in advance Mr. MSG

The only difference between blh83 and me is instead of Au_.exe*32 it shows only Au_.exe.

Originally Posted by Pravin View Post

I dont know where i need to pass the parameters

Parameters isn't a foolproof method, because then the user can still execute the uninstall.exe manually and no parameters will be passed. You should use the FileWriteByte/FileReadByte method:

  FileOpen $0 "$INSTDIR\Uninstall1.exe" a
  FileSeek $0 0 END 
  FileWriteByte $0 ${SomeByte}
  FileClose $0 

do the same for uninstall2.

Then in un.onInit:

  FileOpen $0 $EXEPATH r
  FileSeek $0 -1 END
  FileReadByte $0 $1
  ${If} $0 = ${SomeByte}
    ;uninstall one
  ${Else}
    ;uninstall other
  ${EndIf} 

Thanks a lot MSG. your response helped me a lot.

Originally Posted by MSG View Post

Parameters isn't a foolproof method, because then the user can still execute the uninstall.exe manually and no parameters will be passed. You should use the FileWriteByte/FileReadByte method

That's a pretty clever idea!
Great work, MSG 🙂

Idea leeched entirely from Anders. (Because the appended bytes are not part of the CRC check, he also added basic error checking by adding a number of preset verification bits.)