Installshield 2014 professional: Basic MSI (NOT setup.exe)
Using Project assistant, I set launch application checkbox (default TRUE) on SetupCompleteSuccess dialog.
Usually it works fine.
But on silent mode, it does not work.
How and When can I call IS_LAUNCH_MY_PROGRAM_PLEASE custom action or execute application on installed dirctory.
As an aside, my reaction to this is that you shouldn't do it. If you do, it should be conditional and require the person installing your software to include a property on the command line that requests the program launch.
That said, the problem is that the dialogs are not shown during a silent installation (Windows Installer skips the entire InstallUISequence), so the actions on them will never run. Instead you'd have to schedule a custom action in the InstallExecuteSequence, and use UILevel (and a custom property) to condition when this action runs.
Note that there's a strong likelihood that this will run your application in the wrong context, or even as the wrong user, as typically one has to pre-elevate in order for a silent installation to succeed. So again, keep the request to install an application and the request to run it separate. People using systems like SCCM will curse your installation otherwise.
Related
I am building an installer in Inno Setup v6.2.1 with prerequisites, which include .NET, runtimes, and KB fixes (Windows 7 SP1). The goal is to do potentially several reboots depending on if the machine is missing KBs or .NET etc.
I am able to achieve what I want so far using PrepareToInstall and can change the text by returning the appropriate string. No problems... however I can't find a way of changing the.
Setup must restart your computer. After restarting your computer, run Setup again to complete the installation of xxxxx
Because I am creating a runonce entry, the installer will automatically run after reboot (which it does). The text "run Setup again" is not relevant in my situation and I want to change the text to say that the installer will continue once you restart.
I have tried to find where to change this text but with no success. I assume that PreparingMemo might be the candidate but no luck or not sure how to use it. Any help would be appreciated.
See Handling and customizing errors and messages in Inno Setup.
This particular message is defined by the PrepareToInstallNeedsRestart message.
You can change it in the [Messages] section:
[Messages]
PrepareToInstallNeedsRestart=Setup must restart your computer. After restarting your computer, the Setup will continue to complete the installation of [name].%n%nWould you like to restart now?
If you need to change the message text dynamically, assign WizardForm.PreparingLabel.Caption. E.g. from CurPageChanged(wpPreparing) event.
I've just developed a .NET program which has the ability to patch itself.
I've noticed that the patching process only runs if I choose "run as administrator".
It seems I need to "create and embedd an Application Manifest", according this this:
https://msdn.microsoft.com/en-us/library/bb756929.aspx
So my question:
Is it normal for applications like mine (which can patch themselves) to require Admin rights, and is this the route I should be going?
Thanks
If your application does not normally require elevation then I don't recommend that you request it in your manifest because it will be very annoying for your users. Firefox uses a NT service to get around the UAC dialog but I can't really recommend that either unless your updates are very frequent.
I would suggest that you write a little updater application that does the patching. It can request elevation in its manifest and this way the user only has to elevate when there is something to patch. If you don't want another .exe in your bundle, you can execute yourself again with the runas verb when you need to patch.
Edited the NSIS script to include this line:
AccessControl::GrantOnFile \"$INSTDIR" "(S-1-5-32-545)" "FullAccess"
This gave the User account full access to the application folder within Program Files, meaning my patcher could write to it without any problems.
I am using the Limited edition and in my installer I have a custom action where I open a cmd.exe and passing a batch file for executing.
The cmd is executing but its not in the elevated permission. I need to execute this in elevated permission since my batch file has operations which needs admin privilege.
I tried many options and the screen shots attached describes what I have done.
Let me know if this is possible with Limited Edition. I am installing in windows 10 machine.
the whole "Elevetad privilege" thing changed a lot during the lasts years.
if I were you, I'd put the schema to version 500 (the last one)
you'll might wan't to double check that your batch file is correctly found, as properties in system context can be unavailable. (use /k so the cmd prompt will not close and you'll be able to see the result of your batch file.)
also if the UAC is disabled on the client machine the user won't have the right to elevate your installer so setting the Require Administrative privilege won't change anything.
in order to be sure, you'll might wan't to use a install condition validating the Privileged property.
I created a basic stand-alone msi file using InstallShield 2012. There is a prerequisite that needs to be fulfilled before installation begins. To check this prerequisite, I created an InstallScript-based custom action and added to the very first position in Sequences. If the check fails, the msi should display an error message and then quit. Because the msi will be run both directly via double-clicking and silently via msiexec, the error message should be smart enough to launch a message box during direct install (UI is available) and suppress any message box during silent install (I use "SpretfMsiLog" to write the error message into msi log file).
I tried to run silent install using "msiexec /qn" but the message box still showed up. Is there a way to detect the install mode from with InstallScript code and therefore hide/show the message box accordingly?
The proper approach for this involves using MsiProcessMessage to show the message, as it can parent the window correctly and already knows when not to show it at all. However if you're looking for the minimal changes to what you already have, it's possible that checking the UILevel property will be easier to implement.
An alternative to checking UILevel, would be to check the mode.
if (MODE == SILENTMODE) then
...
endif;
Description: http://helpnet.installshield.com/installshield18helplib/mergedProjects/installshield18langref/LangrefMODE.htm
Folks,
I've got a strange issue at the moment with a visual studio 2010 built MSI...
When I run the msi, it performs a few tasks, then executes a tool we built - this tool then carries out some more advanced work we couldn't do within a custom task.
The issue here, is then when the msi starts my custom built tool, it doesn't execute it with the same credentials as I start the MSI with (i.e. my administrative login).
Is there a parameter I can pass to an MSI to enforece this? Or perhaps I can pass the credentials to the process when I start it?
My process is started using Process process = Process.Start(procInfo) nothing fancy. I've also noted the ability to pass in a parameterised username/password/domain, but this will vary depending on the user who is installing - can this be extracted from the installer somehow?
Any help (or questions) welcomed.
Dave
EDIT: for clarity... I'm running the MSI under my domain account, and I want my custom process to run under that 'context'. At present, it starts (regardless of whether I start as administrator or not) under the SYSTEM account (rather than mydomain\me). I'm using Windows Server DataCenter edition if that helps...
I should also add, I think this is a policy issue, but I've no idea what to check/where to check...
By default Windows Installer runs custom actions as the current user. If the MSI is elevated, custom actions will run as the elevated user.
Please note that if you are running the MSI as an Administrator, it doesn't mean your custom actions will have full Administrator privileges. On Vista or higher any user can gain Administrator privileges through elevation.
So if your custom actions need Administrator privileges, make sure they use the msidbCustomActionTypeNoImpersonate flag so they run under the local system account.
If this is not the problem and you just need access to the current user data, can you please give me more details?