I am creating a Env Variable and then appending it to the PATH variable in my NSIS installer script on Win7 - 64 bit.
Push "MyPath"
Push "D:\MyFolder\bin;D:\MyFolder\lib"
Call WriteEnvStr
Push "%MyPath%"
Call AddToPath
Now after installation I can see both the variable in cmd prompt
MyPath=D:\MyFolder\bin;D:\MyFolder\lib
Path=%MyPath%;<my existsing path>
But any exe/dll from are not found at run time.
If I run the cmd prompt as Administrator and then run exe, it runs fine.
It also works if I run exe directly as an Administrator.
Also interesting is that if I open Environment editor, double click on MyPath variable and click OK (without changing anything), my exe's run fine without running as Administrator.
And now if I check Path in cmd prompt, MyPath variable is substituted
MyPath=D:\MyFolder\bin;D:\MyFolder\lib
Path=D:\MyFolder\bin;D:\MyFolder\lib;<my existsing path>
I tried to add "Call EnvVarUpdate" after creating the env variable but it doesn't work.
I am using NSIS Unicode version 2.46.3
Your chances of adding/modifying the path without losing data in path by truncating it would be much greater by using the registry.
ReadRegStr $0 HKCU "Environment" Path
StrCpy $1 "D:\MyFolder\bin;D:\MyFolder\lib"
StrCpy $2 "$0;$1"
WriteRegStr HKCU "Environment" Path "$2"
If your system has an AUTOEXEC.BAT file then any PATH setting in AUTOEXEC.BAT will also be appended to the %PATH% environment variable. This is to provide compatibility with old installation routines which need to set the PATH. All other commands in AUTOEXEC.BAT are ignored however. And this is more or less obsolete anyway.
But we could just continue with your method however just try a different means of acomplishing your goal. I have not tested this but you can try something similar to this:
StrCpy $R0 "MYPATH"
StrCpy $R1 "D:\MyFolder\bin;D:\MyFolder\lib"
System::Call `Kernel32::SetEnvironmentVariable(t"$R0",t"$R1")`
Now include your new variable in the path like the following:
ReadEnvStr $R0 COMSPEC
ReadEnvStr $R1 MYPATH
ExecDos::Exec /TOSTACK `"$R0" /c "SetX PATH=%PATH%;$R1 -m"`
You can now easily change that one variable %MYPATH% at any time in the future and the PATH will reflect the new value.
${EnvVarUpdate} $0 "PATH" "A" "HKLM" "C:\Program Files\Java\jre6\bin"
StrCpy $R0 "$0"
System::Call 'Kernel32::SetEnvironmentVariableA(t, t) i("PATH", R0).r2'
ReadEnvStr $R0 "PATH"
ExecWait "$INSTDIR\tmp\batchfile.bat
Related
I am using special logging build to generate installation logs.
I have observed the logs are not generating when called another installer from installer script.
For ex -
ExecWait '"$INSTDIR\installer1.exe" /S _?=$INSTDIR'
The log is generating for main installer but not for installer1.exe
The installer1.exe contains lots of components and I need to print the logs for the same. I have tried enabling logset on in the installer1 script but no luck.
Tried using dumplog but it doesn't work with silent installation.
Any help would be appreciated!
Sample code from Main Installer script --
InstallDir "C:\MyFolder"
Name "${PRODUCT_NAME_VERSION}"
OutFile "${OUT_FILE}"
Section "Test"
SetOutPath $INSTDIR
LogSet on
ExecWait '"$EXEDIR\Packages\installer1.exe" /S /INST=$INSTDIR' $0
SectionEnd
Sample code from sub-installer script ---
InstallDir "C:\MyFolder"
Section "-Demo"
SetOutPath $INSTDIR
LogSet on
LogText "Print something"
SetOutPath $INSTDIR\ExternalFolder\Demo
File /nonfatal /a /r $INSTDIR\ExternalFolder\Demo\Test
ExecWait '"$INSTDIR\ExternalFolder\Demo\Test\TestSetup.exe" /silent '
SectionEnd
The sub-installer (installer1.exe) is pre-compiled and kept the exe in $EXEDIR\Packages\installer1.exe The patch is valid.
_?= is special syntax that is only supported by NSIS uninstallers, installers use /D=.
ExecWait '"$InstDir\installer.exe" /S /D=$InstDir'
Logging of course has to be enabled in this sub-installer as well.
/D= overrides the InstallDir attributes, forcing $InstDir to the specified path before .onInit is executed.
InstallDir $INSTDIR does not make sense, use something like InstallDir "$ProgramFiles\MyApp"
My installation EXE should unzip itself in a temp folder, then execute an app therein (with passing args), return and delete the temp folder again.
How do I write the nsi script?
It sounds to me like you are trying to create a portable application. Portable applications are always better when the original author adds support for it because it can handle registry and other configuration files correctly.
If you still want to create a launcher application you can do something like this:
OutFile "MyLauncher.exe"
RequestExecutionLevel User
SilentInstall Silent
SetCompressor LZMA
!include FileFunc.nsh
!insertmacro GetParameters
Section
${GetParameters} $1
InitPluginsDir
SetOutPath $PluginsDir
File "c:\myfiles\MyApp.exe"
File /r "c:\myfiles\otherfiles\*.*" ; If you need to include other files required by the application
ExecWait '"$PluginsDir\MyApp.exe" /param1 "pa ra m2" /param3 $1' $0 ; $1 contains the parameters passed to your launcher, remove it if you don't want to pass those arguments
SetErrorLevel $0
SetOutPath $Temp ; Don't lock $PluginsDir so it can be deleted automatically by the installer
SectionEnd
Answering my own question.
The required nsi script skeleton should look like this:
# The name of the installer (arbitrary)
Name "hello"
# The name of the installation file
OutFile "hello.exe"
# where put the installation - other options would be $TEMP, etc.
InstallDir $DESKTOP
RequestExecutionLevel user # no Windows UAC popup please!
SilentInstall silent # completely silent install
SetCompressor /SOLID /FINAL lzma # max compression for inst. file
# The stuff to install
Section ""
SetOutPath $INSTDIR # where to install (overwritable by user!)
File /r D:\...\... # where the install material lives
SectionEnd
# this function auto-runs after installation is fine
Function .onInstSuccess
# parameter are passed through via $CMDLINE
ExecWait '"$OUTDIR\hello.dist\hello.exe" $CMDLINE'
RMDir /r "$OUTDIR\hello.dist" # remove install folder again
FunctionEnd
I am trying to create and set a directory with NSIS and the accessControl plugin like the following:
CreateDirectory "$APPDATA\${productName}"
; create fileResources directory
CreateDirectory "$APPDATA\${productName}\fileResources"
AccessControl::GrantOnFile "$APPDATA\${productName}\fileResources" "Everyone" "FullAccess"
Pop $0 ; get "Marker" or error msg
StrCmp $0 "Marker" Continue
MessageBox MB_OK|MB_ICONSTOP "Error setting access control for $APPDATA\${productName}\fileResources: $0"
Pop $0 ; pop "Marker"
Continue:
Pop $0
I am receiving the following on $0 what is that response?
I want to make a folder readable and writable by the installed program
I'm guessing that you are building a Unicode installer using NSIS v3 and that you put the wrong plugin in the plugins subdirectory, that is why the result looks chinese.
To install a plugin correctly you need to put the ANSI .dll in NSIS\Plugins\x86-ansi and the Unicode .dll in NSIS\Plugins\x86-unicode.
Function .onInit
DetailPrint "Temp folder - $TEMP"
System::Call 'Kernel32::GetTempFileName(t $TEMP, t "tmp", i 0, t.r0) i.r1
DetailPrint "Temp folder name - $0" //$0 gives empty string
FunctionEnd
When I call Kernel32::GetTempFileName in .onInit function i retrieves an empty file name. But when i call it from section everything is ok!
Can you explain me why?
I recommend you just call InitPluginsDir in .onInit and use $PLUGINSDIR as temp folder. It will be deleted automatically on exit.
$PLUGINSDIR
The path to a temporary folder created upon the first usage of a
plug-in or a call to InitPluginsDir. This folder is automatically
deleted when the installer exits.
It is important to quote all string parameters when using System::Call:
Section
System::Call 'Kernel32::GetTempFileName(t "$TEMP", t "tmp", i 0, t.r0) i.r1'
DetailPrint |$0|
SectionEnd
Please consider using $pluginsdir like the other answer suggests, it is a much better solution because it will not leave behind junk on the end-users machine...
I am new to NSIS, and I need to know that in the uninstaller, how I can check if the application (which is in C++) is running and close it before uninstalling.
Here is a slightly more friendly version for using NSProcess that requests the app to close rather than terminates it (Owen's answer)
${nsProcess::FindProcess} "${APP_EXE}" $R0
${If} $R0 == 0
DetailPrint "${AppName} is running. Closing it down"
${nsProcess::CloseProcess} "${APP_EXE}" $R0
DetailPrint "Waiting for ${AppName} to close"
Sleep 2000
${Else}
DetailPrint "${APP_EXE} was not found to be running"
${EndIf}
${nsProcess::Unload}
Use the NsProcess plugin. Download it here -> NSProcess
How to use it? As simple as:
${nsProcess::KillProcess} "${APP_EXE}" $R4
where APP_EXE is the name of your application...
The download will also tell you how to use it... :)
Depending on the application, you have a couple of choices:
If your application has a window with a somewhat unique class name, you could use FindWindow
If your application creates a named kernel object (Mutex etc) you can check for it by calling the correct native win32 API with the system plugin
Use a 3rd party plugin like FindProcDLL
Just make sure that the first thing that install or un-install does is to delete all xyz.tmp files in %TEMP (or any other app writable directory) before the below for loop runs. No plugins required.
!macro IsRunning
ExecWait "cmd /c for /f $\"tokens=1,2$\" %i in ('tasklist') do (if /i %i EQU xyz.exe fsutil file createnew $TEMP\xyz.tmp 0)"
IfFileExists $TEMP\xyz.tmp 0 notRunning
;we have atleast one main window active
MessageBox MB_OK|MB_ICONEXCLAMATION "XYZ is running. Please close all instances and retry." /SD IDOK
Abort
notRunning:
!macroEnd