Section userSoftware
MessageBox MB_YESNO|MB_ICONQUESTION "Insert user software DVD in to drive and click Yes to install User Software or click No to Proceed" /SD IDNO IDYES yes IDNO no
yes:
AutoCloseWindow true
SetRebootFlag false
Call installUserSoftware
no:
;do nothing
SectionEnd
Section: "userSoftware"
Error: command AutoCloseWindow not valid in Section
This is the error I am getting with AutoCloseWindow. All I am trying to do is after installing the server software if user selects to install Client software, installation of server software should disappear without asking user to hit finish button.
Code I gave I am just testing how AutoCloseWindow or SetAutoClose works, nut all I have is an error!!
AutoCloseWindow is a property like Name and Installdir and must be placed outside functions and sections. If you want to set the autoclose flag at runtime you must use the SetAutoClose command...
Related
I have a custom action (RunEncryption2) that I'm using for encrypting a configuration file by using aspnet_regiis.exe. The custom action type that I'm using is an EXE with path referencing a directory (initial type 34) using deferred execution in system context (so the final type is 3106). The file that I want to encrypt is on INSTALLDIR, so I have a Set Property custom action (SetRunEncryption2, type 51) where I'm setting RunEncryption2=[INSTALLDIR]. My two custom actions look like this:
SetRunEncryption2
Property Name: RunEncryption2
Property Value: [INSTALLDIR]
RunEncryption2
Working Directory: WindowsFolder
File Name & Command line: [WindowsFolder]Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -pef "connectionStrings" "[CustomActionData]" -prov "DataProtectionConfigurationProvider"
When the installer runs, I get no error, however the file gets no encryption at all. When I review the log, I get the following:
MSI (s) (34:C0) [17:32:11:356]: Executing op: CustomActionSchedule(Action=RunEncryption2,ActionType=3106,Source=C:\WINDOWS\,Target=C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -pef "connectionStrings" "" -prov "DataProtectionConfigurationProvider",CustomActionData=C:\Test\)
From the log I can see that the CustomActionData property has been set correctly, however it hasn't been included as part of the command.
At this point the only way I have to make the command work is passing a hard-coded value of INSTALLDIR, otherwise it doesn't seem to work.
I have tried:
Not using CustomActionData, instead passing the value of INSTALLDIR as part of my command line directly.
Using a "Path in Property value" custom action with similar results.
When I run option 1 above, I get a 1722 error on the log:
MSI (s) (C4:50) [12:49:46:968]: Note: 1: 1722 2: RunEncryption2 3: C:\WINDOWS\ 4: C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -pef "connectionStrings" "C:\Test\" -prov "DataProtectionConfigurationProvider"
Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action RunEncryption2, location: C:\WINDOWS\, command: C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -pef "connectionStrings" "C:\Test\" -prov "DataProtectionConfigurationProvider"
MSI (s) (C4:50) [12:49:56:841]: Product: TestEncryption -- Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action RunEncryption2, location: C:\WINDOWS\, command: C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -pef "connectionStrings" "C:\Test\" -prov "DataProtectionConfigurationProvider"
Does anyone know how can I do to correctly execute this command and dynamically pass the value of INSTALLDIR?
Finally found the problem was not in the custom action passing the properties, but in the way that aspnet_iisreg is expecting the parameters.
INSTALLDIR is passing the string with a trailing slash (e. gr. c:\Test\), when I hard coded the installation path I was passing c:\Test instead.
The solution consisted in creating another custom action that removes the trailing slash and stores the value in a new property, this then can be used as parameter for aspnet_iisreg.
By the way, as Michael Urman mentioned, there was no need to use CustomActionData. Thanks.
I have a C program with an installer created by an NSIS script. The issue is one of the files that the installer adds needs to be read only. For this problem I am trying to use the AccessControl plugin. I include the plugin directory with the following line:
!addplugindir "AccessControl\Unicode\Plugins"
At the bottom of my install section I have attempted these lines with no success:
AccessControl::GrantOnFile "$INSTDIR\file.txt" "BUILTINUSERS" "GenericRead + Delete"
AccessControl::GrantOnFile "$INSTDIR\file.txt" "(BU)" "GenericRead + Delete"
AccessControl::GrantOnFile "$INSTDIR\file.txt" "(S-1-5-32-545)" "GenericRead + Delete"
AccessControl::GrantOnFile "$INSTDIR\file.txt" "(S-1-1-0)" "GenericRead + Delete"
There is no error displayed when the script is compiled but after running the installer the file can still be written over. I have had no success from any of these sources.
http://nsis.sourceforge.net/AccessControl_plug-in
http://avidinsight.uk/2014/01/nsis-access-control-problem-with-built-in-users-group/
How do you set directory permissions in NSIS?
http://nsis.sourceforge.net/Talk:AccessControl_plug-in
On a final note I am using Windows 8.
GrantOnFile appends to the existing ACL for the file and never restricts anything. Use SetOnFile to start a new ACL or in your case, use DenyOnFile to deny access for specific groups.
You should also Pop after each call to these functions, the popped string will be "ok" or a error message.
I'm working on a windows 10 app but I've noticed that when I uninstall it it's icon remains in the notification & actions window. what would I need to do or add to my uninstaller to allow it to remove this icon. This is what what uninstaller look like in my .nsi script
Section "Uninstall"
Call un.XXXXXXXXX
ExecWait '"$INSTDIR\f2p_ping.exe" --f2p' $0
; Remove registry keys
DeleteRegKey HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\MyApp"
DeleteRegValue HKCU "Software\Microsoft\Windows\CurrentVersion\Run" "MyApp"
DeleteRegValue HKLM "Software\Microsoft\Windows\CurrentVersion\Run" "MyApp"
DeleteRegKey HKLM "SOFTWARE\MyApp"
DeleteRegKey HKCU "Software\MyApp\Overlay\ExcludedProcesses"
DeleteRegKey HKCR "MyApp"
RMDir /r "$INSTDIR"
RMDir /r $PROGRAMFILES\MyApp
RMDir /r "$APPDATA\MyApp\*.*"
; Remove shortcuts, if any
SetShellVarContext current
Delete "$SMPROGRAMS\MyApp\*.*"
Delete "$SMPROGRAMS\Startup\MyApp.lnk"
SetShellVarContext all
Delete "$SMPROGRAMS\MyApp\*.*"
Delete "$SMPROGRAMS\Startup\MyApp.lnk"
Delete "$DESKTOP\MyApp.lnk"
; Remove directories used
SetShellVarContext current
RMDir "$SMPROGRAMS\MyApp"
SetShellVarContext all
RMDir "$SMPROGRAMS\MyApp"
RMDir "$INSTDIR"
SectionEnd
The best solution is probably to have your application hide the notifications since it already contains notification code. Run something like ExecWait '"$InstDir\MyApp.exe" /uninstall' at the start of your uninstaller.
It might be possible to use one of the IToast* interfaces with the System plugin but there is a lot of code needed and I don't know if Windows let's you pretend to be another application by using its Application Model Id. For example, MSDN has this to say about IToastNotificationHistory::Remove:
The app ID of the app that sent the specified toast notification. This app must be part of the same app package as the app making this remove request.
MSDN also has this to say about desktop apps:
Generally, sending a toast notification from a desktop app is the same as sending it from a Windows Store app. However, you should be aware of these differences and requirements:
For a desktop app to display a toast, the app must have a shortcut on the Start screen.
The shortcut must have an AppUserModelID.
Desktop apps cannot schedule a toast.
In my NSIS script, the MUI_STARTMENU_GETFOLDER macro is not working as expected - instead of giving me the folder that the user actually entered, it gives me the default that I set earlier. Near the beginning of my script I have:
Var StartMenuFolder ; Define variable to hold start menu folder
!define MUI_STARTMENUPAGE_DEFAULTFOLDER "${PRODUCT_PUBLISHER}\${PRODUCT_NAME}" ; Set default start menu folder
!insertmacro MUI_PAGE_STARTMENU Application $StartMenuFolder
I can access $StartMenuFolder in installer (but NOT uninstaller) Sections by use of !insertmacro MUI_STARTMENU_GETFOLDER Application $StartMenuFolder. In uninstaller sections and macros, instead of returning the actual start menu folder, it returns the default folder I specified above.
The MUI_STARTMENU_GETFOLDER macro assumes that you used the MUI_STARTMENUPAGE_REGISTRY_* defines and the MUI_STARTMENU_WRITE_* macros during install (All MUI_STARTMENU_GETFOLDER does is read the registry entry written by the installer (The entry is written in MUI_STARTMENU_WRITE_END if the MUI_STARTMENUPAGE_REGISTRY_* defines are set correctly))
I have a nsi script which starts as following:
Name "myprog"
OutFile "myprog.exe"
InstallDir $PROGRAMFILES32\xx
InstallDirRegKey HKLM "Software\yy\xx" "InstallDir"
RequestExecutionLevel admin
AutoCloseWindow true
BrandingText /TRIMCENTER "me"
LoadLanguageFile "${NSISDIR}\Contrib\Language files\German.nlf"
Caption "Updateprogramm"
It works fine on my dev machine, but not on production (e.g. the user has only readonly permissions for the registry path). It is a Win 2003 server os. Even when the registry key exists, the program tries to install in $PROGRAMFILES32\xx.
InstallDirRegKey only needs read access.
The thing troubling thing for me is that you are talking about read only, but you have "RequestExecutionLevel admin" in your script. This says to me that you require admin rights and when you have "RequestExecutionLevel admin" you also need to use UserInfo::GetAccountType (To handle < NT6 systems and Vista+ when UAC is off)