I need to change an installer script to put the files into C:\Program Files (x86) for 32 bit and C:\Program Files for 64 bit.
I'd hoped $PROGRAMFILES was the right variable to use but from the docs, this always points to C:\Program Files (x86).
"The program files directory (usually C:\Program Files but detected at runtime).
On Windows x64, $PROGRAMFILES and $PROGRAMFILES32 point to C:\Program Files (x86)
while $PROGRAMFILES64 points to C:\Program Files. Use $PROGRAMFILES64 when
installing x64 applications."
I'm familiar with how to test the system at install time with ${If} ${RunningX64} but there are dozens of $PROGRAMFILES entries in the script so I'd like to avoid that approach if at all possible.
Is there a different variable that gets set automatically?
No there is no program files variable that matches the system. $PROGRAMFILES matches the bitness of the installer.
If you need to match the bitness of the system then you have to create your own variable and initialize it in .onInit. $PROGRAMFILES64 probably degrades to $PROGRAMFILES32 on 32-bit systems but I'm not sure if I would endorse using it like that.
This is usually not an issue because you should be using $InstDir when referencing the destination folder.
Related
To avoid installing SDKs on my C: drive which is already low on space, I search a little bit and understand that I have to change SDK installation location through environment variables.
So I find them from here and:
Create ANDROID_HOME=D:\Android\Sdk\ as a User variable
Create ANDROID_USER_HOME=D:\Android\Sdk\ as a User variable
Add ANDROID_HOME and ANDROID_USER_HOME to Path
Run set command in the terminal to make sure everything is set properly
Download Android Studio and start the installation
Then this is what I see:
Android SDK Location still points to my C: drive.
So I quit the installer and this time set both ANDROID_HOME and ANDROID_USER_HOME as SYSTEM variables. Same result.
C:\Users\omids>set
ALLUSERSPROFILE=C:\ProgramData
ANDROID_HOME=D:\Android\Sdk\
ANDROID_USER_HOME=D:\Android\Sdk\
APPDATA=C:\Users\omids\AppData\Roaming
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
COMPUTERNAME=DESKTOP-P8G5R28
ComSpec=C:\WINDOWS\system32\cmd.exe
DriverData=C:\Windows\System32\Drivers\DriverData
HOMEDRIVE=C:
HOMEPATH=\Users\omids
LOCALAPPDATA=C:\Users\omids\AppData\Local
LOGONSERVER=\\DESKTOP-P8G5R28
NUMBER_OF_PROCESSORS=4
OneDrive=C:\Users\omids\OneDrive
OneDriveConsumer=C:\Users\omids\OneDrive
OS=Windows_NT
Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\dotnet\;C:\Program Files\Git\cmd;C:\Program Files\Docker\Docker\resources\bin;C:\ProgramData\DockerDesktop\version-bin;C:\Users\omids\AppData\Local\Programs\Python\Python310\Scripts\;C:\Users\omids\AppData\Local\Programs\Python\Python310\;C:\Users\omids\AppData\Local\Microsoft\WindowsApps;C:\Users\omids\AppData\Local\Programs\Microsoft VS Code Insiders\bin;D:\Android\Sdk\;D:\Android\Sdk\;
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 94 Stepping 3, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=5e03
ProgramData=C:\ProgramData
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files
PROMPT=$P$G
PSModulePath=C:\Program Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules
PUBLIC=C:\Users\Public
SESSIONNAME=Console
SystemDrive=C:
SystemRoot=C:\WINDOWS
TEMP=C:\Users\omids\AppData\Local\Temp
TMP=C:\Users\omids\AppData\Local\Temp
USERDOMAIN=DESKTOP-P8G5R28
USERDOMAIN_ROAMINGPROFILE=DESKTOP-P8G5R28
USERNAME=omids
USERPROFILE=C:\Users\omids
windir=C:\WINDOWS
ZES_ENABLE_SYSMAN=1
I know I can change that path manually and proceed with installation, but if Android Studio cannot read those variables or ignores them I'm sure I'll have issues down the road.
Trying to run a batch file at the end of an installation, everything works great except this file won't run.
section "Startup"
Exec '"$0" /C "C:\Program Files\placeholder\startup\startup.bat"'
sectionEnd
Everything gets deposited in the right spot, using absolute pathing to call this. I asked for administrator privileges at the start,
RequestExecutionLevel admin ;Require admin rights on NT6+ (When UAC is turned on)
Just copying from the example NSIS installer provided here
The file is there so I must be making a mistake with the file path or missing some parameter. Been trying a lot of permutations like nsExec but not sure my mistake. Hopefully this is a simple mistake and will aid others in the same boat at some time.
Without more information I would guess that this is a 64-bit Windows machine and filesystem redirection is causing your 32-bit installer to access the wrong program files directory.
The code you posted is also problematic because we don't know what $0 is. I assume you failed to post the code where it expands %comspec%. To rule out this, replace $0 with $sysdir\cmd.exe.
Ideally your installer should extract the batch file to the destination directory:
Section
SetOutPath $InstDir
File batch.bat
ExecWait '"$sysdir\cmd.exe" /C if 1==1 "$InstDir\batch.bat"'
SectionEnd
If you must access the 64-bit folder you can disable the redirection but this is not recommended:
!include x64.nsh
Section
${DisableX64FSRedirection}
ExecWait ... $ProgramFiles64\...
${EnableX64FSRedirection}
SectionEnd
I think that you should give us more information to solve this problem.
Based on current information, I guess there are two reasons:
"C:\Program Files" is a path for 64-bit programs, but NSIS installer is a 32-bit program, so this path will be redirected to "C:\Program Files (x86)". You can use the solution from Anders to solve it.
Your batch file may contains relative paths. When you run your batch file from the NSIS installer, your working directory is not as same as your batch file. Due to this, some command cannot run correctly. You can use %~dp0 to solve it.
I am using the below statements to delete the files and subdirectories from the installed directory.
RMDir /r "$INSTDIR\*.*"
RMDir "$INSTDIR"
While uninstalling, it doesn't delete the uninstall.exe file alone from the installed directory.
Please let me know your suggestions on this.
Have you tried the /REBOOTOKflag?
Take notice of this warning from the scripting reference:
Warning: using RMDir /r $INSTDIR in the uninstaller is not safe.
Though it is unlikely, the user might select to install to the Program
Files folder and so this command will wipe out the entire Program
Files folder, including other programs that has nothing to do with the
uninstaller. The user can also put other files but the program's files
and would expect them to get deleted with the program. Solutions are
available for easily uninstalling only files which were installed by
the installer.
During my installation of Nodist, the node version manager for Windows, I encountered an alert message that stated:
PATH not updated, original length 1030 > 1024
The result was that even Nodist was installed successfully(per installation feedback), entering 'nodist' at git bash at directory levels other than its resident directory (C:\Program Files (x86)\Nodist\bin) yielded:
'nodist' is not recognized as an internal or external command,operable program or batch file.
How can one set up PATH manually?
Since nodist can be accessed from the directory of C:\Program Files (x86)\Nodist\bin and not anywhere else, placing the path
C:\Program Files (x86)\Nodist\bin
in the System Variables (accessible from Window's Advanced System Settings/Environmental Variables) corrects the problem. Many thanks to Marcel Klehr for the pointer.
I am building a plugin for NSIS with VS 2010 and I would love to set up the project so that a test setup is automatically built from a simple NSI file.
All seems fine except I can't figure out how to make NSIS look for my plugin in my project's output folder instead of C:\Program Files (x86)\NSIS\Plugins\*.dll only.
Are there any commands I can put in my NSI script to make NSIS look for my freshly built plugin outside of "standard plugins folder"? It seems rather odd to have to copy my DLL each time I wanted to test it.
Any help is appreciated.
You can use !addplugindir directive, see nsis compile-time commands.
Use !addplugindir directive with defined symbol (/D on command line).
Symbol is "the path to your location of .dll file"
For VS 2010 is the best option to use Visual & Installer - free VS addin for developing NSIS installers directly in Visual Studio.
Set your symbol in Project properties:
Download here: www.unsigned-softworks.sk/visual-installer/
As others have mentioned, the !addplugindir directive in your NSI script file will do the trick, and you can define a variable to pass to that directive on the command line using /D.
As for the code to add to your NSI file, you need something like this:
!ifdef EXTRANSISPLUGINSFOLDER
!addplugindir "${EXTRANSISPLUGINSFOLDER}"
!endif
Then on the command line, you can call your NSI script like this:
makensis.exe /DEXTRANSISPLUGINSFOLDER=C:\somefolder\moreplugins\ YourInstallerScript.nsi
When defining the extra folder, you might find that having any spaces in the folder path causes problems, and using quotes around the path doesn't help. To work around this, try using the dir /x command in the Windows terminal to list the 8.3 DOS names for the folders with spaces in their name. This will help you build up a folder path that doesn't contain spaces. (eg C:\Program Files\ often becomes C:\PROGRA~1 when listed with dir /x from the root of C:)
May have missed the point here but could you not have used an XCOPY post build event to copy the output to the NSIS plugins directory?