I have this issue:
in the installer sections I have this;
Section "Start Menu Shortcuts"
SetShellVarContext current
CreateDirectory "$SMPROGRAMS\myProgram"
CreateShortCut "$SMPROGRAMS\myProgram\myProgram.lnk" "$INSTDIR\myProgram.exe"
CreateShortCut "$SMPROGRAMS\myProgram\Uninstall myProgram.lnk" "$INSTDIR\myProgram-Uninstall.exe"
SectionEnd
Section "Desktop Shortcut"
SetShellVarContext current
CreateShortCut "$DESKTOP\myProgram.lnk" "$INSTDIR\myProgram.exe"
SectionEnd
and it works fine, I have the icon on the desktop and the icon plus the uninstall icon on the start\programs... tree
the uninstaller section is like this:
SetShellVarContext current
Delete "$DESKTOP\myProgram.lnk"
Delete "$SMPROGRAMS\myProgram\myProgram.lnk"
Delete "$SMPROGRAMS\myProgram\Uninstall myProgram.lnk"
RMDir "$SMPROGRAMS\myProgram"
and the desktop link was deleted, but the other folder with the links not..
any ideas?
the folder where is stored is this (i'm on win 7 64 bits):
C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs
Do you have RequestExecutionLevel in your script? Without it Windows might do some compatibility hacks with your shortcuts.
If that does not help, try Process Monitor, it might be able to shed some light on the issue...
Related
In order to sign both the installer and uninstaller, I have created a separate uninstaller script as suggested here: https://nsis-dev.github.io/NSIS-Forums/html/t-245688.html. Thus, the uninstaller script not using the WriteUninstaller way to create the uninstaller.
Please note that I am using the SelfDel plug-in to delete the uninstaller, which works successfully; however, it does not actually delete the application install directory even though I am using the /RMDIR option:
Function .onInstSuccess
;SelfDel::Del /REBOOT
;SelfDel::Del /SHUTDOWN
SelfDel::Del /RMDIR
SelfDel::Del
SetAutoClose true
FunctionEnd
Here is the full script for your reference.
!define APP_COPYRIGHT "MyApp © MyCompany 2021"
!define COMPANY_NAME "MyCompany"
!define LANG_ENGLSH "English"
!define PRODUCT_NAME "MyApp"
!define PRODUCT_VERSION "${MAJOR_VERSION}.${MINOR_VERSION}.${PATCH_VERSION}.${BUILD_VERSION}"
!define SETUP_NAME "uninstaller.exe"
# define the name of the installer
OutFile ${SETUP_NAME}
Icon "favicon.ico"
!define MUI_ICON "favicon.ico"
# define the directory to install to
InstallDir "$PROGRAMFILES64\${PRODUCT_NAME}\"
# default section
Section
# define the output path for this file
SetOutPath $INSTDIR
# now delete installed files and registry keys for MyApp
ReadRegStr $0 HKCU "SOFTWARE\${PRODUCT_NAME}" "InstallLocation"
DeleteRegKey HKCU "SOFTWARE\${PRODUCT_NAME}"
Delete $0\config.dat
Delete $0\MyApp.exe
Delete $0\ReleaseNotes.txt
Delete $0\MyApp_LandingPage_114.bmp
Delete $0\MyAppLicense.txt
Delete "$SMPROGRAMS\MyApp.lnk"
DeleteRegKey HKCU "SOFTWARE\${PRODUCT_NAME}"
DeleteRegKey HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${PRODUCT_NAME}"
DeleteRegKey /ifempty HKCU "Software\Modern UI Test"
SectionEnd
Function .onInstSuccess
;SelfDel::Del /REBOOT
;SelfDel::Del /SHUTDOWN
SelfDel::Del /RMDIR
SelfDel::Del
SetAutoClose true
FunctionEnd
Does anyone have any suggestions on how to get it to delete the app directory? TIA.
So I don't really know the SelfDel nsis plugin that well, but have you tried just restarting your machine after deleting your install-directory like so?
SelfDel::Del /RMDIR
SelfDel::Del
SelfDel::Del /REBOOT
;or just
Reboot
That might help.
Wish you all the best.
Update
Ok so you tried to Reboot.
I researched a little further on the topic and found the same problem, but without the SelfDel plugin: How to solve "The directory is not empty" error when running rmdir command in a batch script?
But maybe you could also try to remove the directory and all the files in the "normal NSIS way" like this:
RMDir /r $YOURDIR
Try this maybe it will work, and perhaps it's just some bug from the plugin.
The SourceForge site of the plugin says it's only testet on Windows 8, so if you are using it on Windows 10 there might be some bugs.
Read the note at the bottom of the SourceForge site: https://nsis.sourceforge.io/SelfDel_plug-in
They say that it is a Trojan Virus and I would recommend to stop using it.
I would seriously consider using another plugin that is testet for Windows 10.
Wish you all the best.
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.
the fat jar opens fine in the location i specified but it wont open when i call it through a desktop shortcut. Although if I right click on the icon and say open file location, it opens the correct file.
SetOutPath $INSTDIR
SetOverwrite on
File C:\jitconsole\JITConsole\jitconsole.jar
SetOutPath $INSTDIR\images
File C:\jitconsole\JITConsole\images\*
SetOutPath $INSTDIR\lib
File C:\jitconsole\JITConsole\lib\*
SetOutPath $DESKTOP
CreateShortcut $DESKTOP\JIT.lnk $INSTDIR\jitconsole.jar "" $INSTDIR\images\JIT_medium.ico
any help would be greatly appreciated
thanks
A .jar could open in any application, on my system it is set to open in WinRar!
You should create a shortcut that executes the correct command line:
CreateDirectory $Desktop ; Make sure desktop exists
SetOutPath $Instdir ; Sets the .lnk working directory
CreateShortcut "$DESKTOP\JIT.lnk" "c:\path\to\java.exe" "$INSTDIR\jitconsole.jar" "$INSTDIR\images\JIT_medium.ico"
This means you need to figure out the java path in the installer and if the java path changes your shortcut might break. It is probably a better idea to use a java loader app:
CreateDirectory $Desktop ; Make sure desktop exists
CreateShortcut "$DESKTOP\JIT.lnk" "$INSTDIR\MyJavaLoaderForMyApp.exe" "" "$INSTDIR\images\JIT_medium.ico"
How can I create desktop shortcuts for all user while installing a package?
NSIS supports several of the common/shared special folders:
SetShellVarContext all
CreateShortcut "$desktop\myapp.lnk" "$instdir\myapp.exe"
This code assumes you are elevated...
With !include NTProfiles.nsh [1] you can create a shortcut in the folder "${ProfilePathAllUsers}\Desktop".
[1] - http://nsis.sourceforge.net/NT_Profile_Paths
Is there any way to tell NSIS not to overwrite my start menu shortcut. The reason I don't want it to overwrite is so the user's command line options aren't cleared when they upgrade to a new version. I've tried this to no avail:
Section -AdditionalIcons
SetOverwrite off
CreateDirectory "${START_MENU_DIR}"
CreateShortCut "${START_MENU_LNK}" "$INSTDIR\${PRODUCT_NAME}.exe"
SectionEnd
Why can't you just check with IfFileExists ?
If you wanted to go all out, you could update the path and working dir, but leave the parameters and icon in place, but to do that you would have to call the IShellLink COM interface on your own (With the system plugin or a custom plugin/app)
Here is an example that works:
Section -AdditionalIcons
CreateDirectory "${START_MENU_DIR}"
IfFileExists "${START_MENU_LNK}" SkipShortcut
CreateShortCut "${START_MENU_LNK}" "$INSTDIR\${PRODUCT_NAME}.exe"
SkipShortcut:
SectionEnd