I am currently extracting some files needed by the installer in a folder placed in the Windows temp directory. The way I have set it now is that that folder has a unique name based on the product name as well as the date.
The problem is that the whole folder name variable is set at installer build time and not when the installer is run, which means that I don't have a new temporary folder each time the same installer is run.
The code I'm using to create the folder is:
; Support folder
; this folder will contain temporary files visibible only for the lifetime of the installation
!define /date SUPPORTDIR "$TEMP\${PRODUCT_NAME}_%y%m%d%H%M%S"
var InitSupportDirDone
function InitSupportDir
${if} $InitSupportDirDone != 1
SetOutPath "${SUPPORTDIR}"
!include supportfiles.nsh
StrCpy $InitSupportDirDone 1
${endif}
functionend
This causes my SUPPORTDIR to be already set, as can be seen from the build log:
!define: "SUPPORTDIR"="$TEMP\Test-Proj_130911164903"
How can I change this so that the date (and folder name) is set each time the installer runs instead of at build time?
You could create a loop, starting with a 0 suffix and increasing it as long as a folder with that name exists but in you case you don't have to, just call InitPluginsDir in .onInit and use $pluginsdir as your temp folder...
Related
I have an application which has development, testing and live versions. I have a command procedure which currently creates 3 different versions of the installer, which can be installed on 3 separate computers.
What I would like to do would be to have one NSIS script which I pass in a parameter to, which will create one of the versions of the installer changing the name of the product and the installation folder. This will allow me to install all 3 versions on the same computer.
What I have tried so far is;
Function .onInit
Var /GLOBAL INSTALL_TYPE
${GetOptions} $CMDLINE "/t" $INSTALL_TYPE
${if} $INSTALL_TYPE == ""
StrCpy $INSTALL_TYPE "Live"
ReadEnvStr $R0 SYSTEMDRIVE
StrCpy $INSTDIR "$LOCALAPPDATA\Programs\MyComp\MyApp$INSTALL_TYPE\"
FunctionEnd
!define MUI_PRODUCT "FCDS-RECAP$INSTALL_TYPE"
OutFile "MyApp-$INSTALL_TYPEinstaller.exe"
One of the main errors I get has to do with MUI_PRODUCT and look similar to;
warning 6000: unknown variable/constant "INSTALL_TYPE.lnk" detected, ignoring (FullDeploymentUser.nsi:121)
warning 6000: unknown variable/constant "INSTALL_TYPE" detected, ignoring (FullDeploymentUser.nsi:124)
Two types of comments would be useful;
This is what you are doing wrong...
This is what you should be doing...
As always any help is appreciated.
MUI_PRODUCT is technically not an official NSIS define, some guy just invented it and used it in a guide.
All instructions starting with ! are preprocessor instructions, those and OutFile and File cannot be controlled by ${GetOptions} because they happen at compile time on your developer machine.
I don't really recommend this 3 in 1 installer solution, it is a bit complicated. It is much better to just create 3 different installers:
!ifndef APPTYPE
!error "APPTYPE not defined"
!endif
Name "MyApp ${APPTYPE}"
OutFile "MyApp ${APPTYPE} setup.exe"
InstallDir "$ProgramFiles\MyApp ${APPTYPE}"
Page Directory
Page InstFiles
Section
SetOutPath $InstDir
File /r "c:\myfiles\MyApp\${APPTYPE}\*"
SectionEnd
and then just generate them with makensis -DAPPTYPE=Beta myapp.nsi etc.
If you really want this 3 in 1 style then you need to use the macros in Sections.nsh to manipulate the sections so that only one of them is visible and active. You also need to mark the install somehow (.ini file?) so that your uninstaller also knows which install type it is uninstalling.
I'm working on a installer script that needs to install one of two folders based on the OS bits. The selection occurs fine so far but for some reason I only see one folder within the resulting installer.
The relevant sections are below:
;Windows 32 or 64 bit version
!include "x64.nsh"
Section "JRE 64 Bit" Section5
SectionIn RO
;Use the right java version
DetailPrint "JRE extraction..."
SetOutPath "$INSTDIR\${APPDIR}\jre"
File /a /r "${SrcDir}\..\..\jre\jre_64\jre\*.*"
DetailPrint "JRE extraction complete!"
SectionEnd
Section "JRE 32 Bit" Section6
SectionIn RO
;Use the right java version
DetailPrint "JRE extraction..."
SetOutPath "$INSTDIR\${APPDIR}\jre"
File /a /r "${SrcDir}\..\..\jre\jre_32\jre\*.*"
DetailPrint "JRE extraction complete!"
SectionEnd
Function .onInit
#Determine the bitness of the OS and enable the correct section
IntOp $0 ${SF_SELECTED} | ${SF_RO}
${If} ${RunningX64}
SectionSetFlags ${Section5} $0
SectionSetFlags ${Section6} ${SECTION_OFF}
${Else}
SectionSetFlags ${Section5} ${SECTION_OFF}
SectionSetFlags ${Section6} $0
${EndIf}
FunctionEnd
Both folders exists as there is no warning. But instead of seeing two folders (jre_64 and jre_32) I just see one jre folder within the installer.
Is this expected behavior? I'm using NSIS 2.51. The resulting instaler can be found here.
You can see the full script here.
I guess it's because of the delta compression, as the two jre directories should have quite similar contents. The structure when viewing using 7-Zip doesn't necessarily represent the internal structure of the installer, which seems to be quite opaque.
I tried to find a tool to "properly" unpack the installer (like innounp for Inno Setup), but without success. This confirms the NSIS installer structure should be really opaque.
Did you do some manual testing to determine if the installer works as expected in both cases?
The path used in File instructions are not stored in the installer (except for the last path component if it is a folder), it is used to find the files on your development system. As you probably know, SetOutPath sets the destination directory and decompilers can only display parts of that path (they cannot resolve custom variables) and you used just "jre" for both the 32-bit and 64-bit folders.
7-zip is not a full decompiler, it only does what is needed to find the destination path names and it does not understand that there are really two different jre folders selected by your if statements.
NSIS will only store identical files once, add SetDatablockOptimize off to the top of your script and your installer will probably double in size.
I'm new to NSIS and creating one installer for our project.
The requirement is: there are 1 folder and 2 exes needs to be installed as part installation. These exes are created using nsis (Y.exe, Z.exe). These exes should be installed in different destination folder. I've tried this two approches:
Approach 1:
in script these variables assigned
RUN_Y C:\Installer\misc_exe\y.exe
RUN_Z C:\Installer\misc_exe\y.exe
Y_INSTALL_DIR INSTDIR\Y\ # INSTDIR is specified by user during folder installation
Z_INSTALL_DIR INSTDIR\Z\ # INSTDIR is specified by user during folder installation
# calling this at the time exe installation
setoutpath SetOutpath "${Y_INSTALL_DIR}"
ExecWait '"${RUN_Y}"'
setoutpath SetOutpath "${Z_INSTALL_DIR}"
ExecWait '"${RUN_Z}"'
Problem is, the destination folder is always coming as C:\Installer\misc_exe\ , whereas it should be C:\Y\. How can I fix it?
Approach 2:
While creating the zipped folder to exe, I gave destination folder as $INSTDIR/Y/ and $INSTDIR/Z/, and I think, this $INSTDIR is taken from the 1st folder installation. But, its not working that way.
can anyone help with me with how can I do specific folder installation?
Thanks in advance.
I am not sure what are you trying to do but to set target directory use
InstallDir "C:\Y\"
command.
Got another newbie NSIS question. Here's the script:
; -*-nsis-*-
Name "ndhtest"
OutFile "FooStartMenuTest.exe"
XPStyle on
!define FOO_SRC c:\users\nhughes\foo
InstallDir "$PROGRAMFILES\Initech\"
Icon ${FOO_SRC}\foo_logo.ico
UninstallIcon ${FOO_SRC}\uninstall.ico
Page instfiles
UninstPage uninstConfirm
UninstPage instfiles
Section
SetOutPath $INSTDIR
File ${FOO_SRC}\foo.bat
WriteUninstaller "$INSTDIR\uninstall.exe"
CreateDirectory $SMPROGRAMS\Initech
CreateShortCut $SMPROGRAMS\Initech\Foo.lnk $INSTDIR\foo.bat "" \
"${FOO_SRC}\foo_logo.ico"
CreateShortCut $SMPROGRAMS\Initech\Uninstall.lnk $INSTDIR\uninstall.exe "" \
"${FOO_SRC}\uninstall.ico"
SectionEnd
Section "Uninstall"
Delete $SMPROGRAMS\Initech\Foo.lnk
Delete $SMPROGRAMS\Initech\Uninstall.lnk
RMDir $SMPROGRAMS\Initech
Delete $INSTDIR\Foo.bat
Delete $INSTDIR\uninstall.exe
RMDir $INSTDIR
SectionEnd
The uninstall seems to work except for leaving the shortcuts under ProgramData:
Directory of c:\ProgramData\Microsoft\Windows\Start Menu\Programs\Initech
08/10/2011 04:07 PM <DIR> .
08/10/2011 04:07 PM <DIR> ..
08/10/2011 04:23 PM 1,847 Foo.lnk
08/10/2011 04:23 PM 1,885 Uninstall.lnk
2 File(s) 3,732 bytes
2 Dir(s) 1,387,345,117,184 bytes free
What is my script getting wrong that is leaving this stuff hanging around?
Here is what the uninstaller writes to its console (I added a DetailPrint message listing $SMPROGRAMS):
smprograms=C:\Users\nhughes\AppData\Roaming\Microsoft\Windows\Start Menu\Programs
Remove folder: C:\Users\nhughes\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Initech\
Delete file: C:\Program Files (x86)\Initech\foo.bat
Delete file: C:\Program Files (x86)\Initech\uninstall.exe
Remove folder: C:\Program Files (x86)\Initech\
Completed
So the links under ProgramData never get referred to, it's looking for the links under AppData\Roaming instead.
I'm testing this on Windows 7, but the core problem here is I would like to be able to write a script that works on everything from XP to Windows 7, regardless of all the changes in how Windows squirrels away stuff in different spots in different versions. This is looking like it might be painful.
If DetailPrint is added to the nsis script, it starts to be apparent that NSIS tries to create the files under C:\Users, but they are actually created in c:\ProgramData. This ProgramData directory is a strange thing, because it's not visible with dir C:\, however it's possible to enter the directory with cd. Such mysteries are caused by Virtual Store, a tricky feature of Windows 7.
Now to the solution. Windows applications should define their execution level, otherwise system may behave in an unexpected way. You remember some applications ask whether to install "for current user only" or "for all users"? That's the thing we need to declare.
If we insert nsis instruction RequestExecutionLevel user, then the shortcuts are made for current user. If we do RequestExecutionLevel admin, then we should also add SetShellVarContext all to both install and uninstall sections.
This answer is based on the article from nsis wiki: Shortcuts removal fails on Windows Vista, where examples are given for both approaches.
From the spec:
4.9.1.8 RMDir
[/r] [/REBOOTOK] directory_name
Remove the specified directory (fully qualified path with no wildcards). Without /r, the directory will only be removed if it is completely empty. If /r is specified, the directory will be removed recursively, so all directories and files in the specified directory will be removed. If /REBOOTOK is specified, any file or directory which could not have been removed during the process will be removed on reboot -- if any file or directory will be removed on a reboot, the reboot flag will be set. The error flag is set if any file or directory cannot be removed.
Try adding the /r to the RMDir lines to force it to flush the contents. Either that or remove the links individually.
I have multiple instances of a program and each has its own install directory with its own copy of the uninstaller. The installer has a field called "$instance" entered by the user which is recorded in the registry like this:
HKLM "SOFTWARE\#vendor.name#\#product.name# #product.version#\installs\$instance"
which works fine. This key contains the root path of the install.
I would like to uninstall the instance of the program that corresponds to the uninstaller that is executed but the Uninstall section does not retain the variable "$instance" that the user entered at install time.
Any ideas?
Example:
Section Uninstall
; THIS does not display the instance name. :(
MessageBox MB_OK "$instance"
SectionEnd
You can store custom data at the end of the uninstaller.exe without breaking the CRC check, or alternatively store it in a .ini in the same directory as the uninstaller (I do this all the time, just name the ini file "uninstaller.dat" or something like that so users don't mess with it)