Installer not setting environment variables second time around.

[pgg1]

Hi

I have an installer that installs my application and sets environment variables. I set these variables using kichik's script and the SetEnv.dll. I use SetEnv.dll to launch the application from the finish page. Everything work greats.

I've recently changed my script so now we uninstall any older versions of our application (if one is installed) and then install the newer one.

The problem is that the environment variables do not get set the second time around, for example:

(1) Install application (adds Environment variables).
(2) Uninstall the application using installer.exe, this removes the environment variables.
(3) Install application (DOES NOT add the Environment variables) therefore application cannot start.

Does anyone have any suggestions?

Regards

Paul

[kichik]

Did you execute the uninstaller from the installer? If so, the installer didn't get a chance to update its environment table and so it thinks the environment variable is still set and therefore doesn't set it again.

[pgg1]

Yes I did execute the uninstaller from the installer. How do I get around this problem?

Regards

Paul

[kichik]

Manually modify the environment variables for the working installer as well. Use:

http://nsis.sourceforge.net/Setting_Environment_Variables_to_Active_Installer_Process

[pgg1]

Sorry I don't quite get what your saying. Could you clarify what you meant please.

At the moment I use: http://nsis.sourceforge.net/Path_Manipulation
to set my environment variables, and this is done within a section.

I am already using:
http://nsis.sourceforge.net/Setting_Environment_Variables_to_Active_Installer_Process
in a function, and this function gets called from the active installer (i.e. finish page) so I can launch the application from the installer.

[kichik]

But you don't remove the path from the installer's environment after the uninstaller is executed.

[pgg1]

Isn't that just solving one problem and creating another? If I don't clean up after an uninstall then after numerous installs each one representing a newer release I will be adding duplicate environment variables. I've just tested:

http://nsis.sourceforge.net/Path_Manipulation

and it just concatenates to the end without any checking to determine if the environment variable your adding is already contained within.

Regards

Paul

[pgg1]

I have a solution, I'll post what I have done later as I don't have time right now.

[pgg1]

I've taken this from a post last year.


; This function allows us to add/remove directories to/from the system path.
!macro SetSystemPath un_
function ${un_}SetSystemPath
# stack top: <'string to add'> / <AppendFlag>
Exch $0 ; new string
Exch
Exch $1 ; append = 2, prefix = 1, remove = 0
Push $R0 ; saved working registers

ReadRegStr $R0 HKLM "${REGISTRY_ENVIRONMENT}" "Path"

${Select} $1
${Case} 0
${${un_}WordAdd} "$R0" ";" "-$0" $R0
${Case} 1
${${un_}WordAdd} "$0" ";" "+$R0" $R0
${Case} 2
${${un_}WordAdd} "$R0" ";" "+$0" $R0
${EndSelect}

WriteRegExpandStr HKLM "${REGISTRY_ENVIRONMENT}" "Path" "$R0"
Pop $R0 ; restore registers
Pop $1
Pop $0
SendMessage ${HWND_BROADCAST} ${WM_WININICHANGE} 0 "STR:Environment" /TIMEOUT=5000
functionEnd
!macroend
!insertmacro SetSystemPath ""
!insertmacro SetSystemPath "un."


I then use it like this in a section:

Push 2 ; 2 = append.
Push ${DLLS_ABSOLUTE_PATH}
Call SetSystemPath

WriteRegExpandStr HKLM "${REGISTRY_ENVIRONMENT}" "${ZANG_HOME}" "$INSTDIR"
SendMessage ${HWND_BROADCAST} ${WM_WININICHANGE} 0 "STR:Environment" /TIMEOUT=5000

WriteRegExpandStr HKLM "${REGISTRY_ENVIRONMENT}" "${FFMPEG_HOME}" "$INSTDIR\ffmpeg"
SendMessage ${HWND_BROADCAST} ${WM_WININICHANGE} 0 "STR:Environment" /TIMEOUT=5000


and uninstall:


; Remove System variables.
Push 0 ; 0 = remove
Push ${DLLS_ABSOLUTE_PATH}
Call Un.SetSystemPath

; Remove User variables.
Push ${ZANG_HOME}
Push $INSTDIR
Call un.RemoveFromEnvVar

Push ${FFMPEG_HOME}
Push "$INSTDIR\ffmpeg"
Call un.RemoveFromEnvVar


It's ugly but it works, if anyone has any further thoughts I'd appreciate them.

Regards

Paul