I've created a Basic MSI project and have a fully functional installer. Some directories need path values found in the registry. I have a few "Set Directory" custom actions to handle this for me. The regular GUI installer works just fine, but the silent install doesn't seem to run any of the "Set Directory" custom actions. What do I need to do to make these custom actions set my directory properties correctly?
Any help would be appreciated. Here is an example of one such custom action:
Directory Name: DIRECTORYNAME
Directory Value: [REGISTRYPATH]\subpath
Execution Scheduling: Always execute
Install UI Sequence: After PathWelcome
Install Condition: [REGISTRYPATH]
Schedule your custom actions in both InstallUISequence and InstallExecuteSequence. Silent installs use only InstallExecuteSequence.
Type 35 Custom Actions ( Set Directory ) must come after CostFinalize. If you need it before CostFinalize use Type 51 ( Set Property ) Custom Actions. I don't know what PathWelcome is so I can't tell you which to use.
Also read the following for advanced considerations to take into account.
http://blog.deploymentengineering.com/2011/01/blair-symes-recently-posted-building-32.html
Related
I have created an installer using Inno Setup. The installer uses a packaged-in DLL to check availability of a specific device on the target machine. If the device is found, the installation is allowed to finish, otherwise the installation is rolled-back (rollback is done using below lines in script):
if <DeviceNotFound> then
begin
CancelWithoutPrompt := true;
WizardForm.Close;
end;
I have checked that the above check and rollback logic works fine if the setup is run with /silent cmd line param. However, when I use /silent param, the setup displays the Installation progress wizard form.
Also, I found that if I run the above setup in /verysilent mode, then the "DeviceNotFound" check logic works fine but the rollback logic doesn't work and it seems as if rollback logic doesn't get executed at all. Instead of performing rollback, the installer successfully installs.
Now, I have a requirement to run the setup silently so that no window is displayed but it must install or rollback based on device check. Therefore, I have the below queries:
Can I rollback the installer when it is running in /verysilent mode? If so, please advise how it may be achieved. I can detect verysilent install mode as shown in question:
How to detect whether the setup runs in very silent mode?
Alternatively, can I Hide/Minimize the Installation progress window when it is running in /silent mode? If so, please advise how it may be achieved.
Please help me with my above queries.
Sorry to be so descriptive but I tried to explain my problem and queries!
EDIT
I am not doing the above mentioned check in InitializeSetup(). I am doing the check from a function invoked by AfterInstall directive from [Files] section. I have a limitation that I cannot do it from InitializeSetup() as the packaged-in DLL is not extracted till [Files] section completes. I also need to run the installer in Windows PE (Preinstallation Environment), hence I cannot use ExtractTemporaryFile() function to forcefully extract the DLL because the {tmp} path is not valid in that environment. That leaves me with only one option is to check after [Files] section is done. Please advise!
Your constraint on not using ExtractTemporaryFile does not make sense.
The Inno Setup installer always creates a temporary folder for the installation.
2015-07-31 09:02:07.458 Created temporary directory: C:\Users\martin\AppData\Local\Temp\is-1CN29.tmp
If it is not possible to create the folder, the installation fails.
The Inno Setup tries to create the temporary folder in these locations:
%TMP%
%TEMP%
%USERPROFILE%
Windows installation folder (C:\Windows)
At least the last path has to exist even in the "Windows PE".
So I do not think, there's anything preventing you from using the ExtractTemporaryFile function.
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.
I am trying to construct a silent install using Inno Setup. I am using the /SILENT and /VERYSILENT command parameters, and everything works fine, except for the UAC window popping up at the start.
How do I get around this issue?
I have found a few posts loosely mentioning about using SignTool, but other sources have said that this will simply change the UAC box blue with the publisher parameter filled.
Can anyone help here? The scenario is an installer which will be distributed over the internet to update existing software on a machine silently without any user interaction.
To run a setup elevated without the UAC prompt, you need to run it from something that is already elevated. It would defeat the entire point of UAC if programs could elevate without the user controlling access.
Signing the executable does just show the publisher.
The basic idea is to first install a service that runs under the Local System account, and this service will launch your update installers so that updates can bypass UAC, and don't force the end user to run as admin. If you don't want to develop one on your own, there are 3rd party solutions like this:
http://www.autoupdateplus.com/
When your users first install your application, an "updater service" gets installed, and all subsequent updates can be silent.
(We used to use AutoUpdate+, but later decided to roll our own which just downloads the full installer file of our appliation and runs it silently. This wasn't possible with AutoUpdate+, we had to create update packages with the changed files, which turned out to be too much hassle, with too much room for error.)
I have found one solution of it, like If I do the following before Installing my EXE for temporary then on post Installation I revert it. then, I hope my purpose get solved.
[Registry] Root: "HKLM"; Subkey: "SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"; ValueType: dword; ValueName: "ConsentPromptBehaviorAdmin"; ValueData: "0x00000000"
You can install it as User Software. Then you have no problems with UAC because it is no system wide software. ProgramData must be stored in User Folders and Registery Settings must be done under CurrentUser.
Not sure if you like to do that.
But anyway. You do not have to take care of UAC. Companies will have a deployment server with elevated rights so silent deployment will not force there a UAC message.
The UAC message is the normal behavier
Does anyone know if I NEED To wrap my Office 2007, vsto-based add-in in a MSI? It seems to be a lot of extra overhead and headache, just to have it not work anyway.
When I do get it to install, I still need to run the vsto installer, even though I have tried to use the |vstolocal switch to keep the add-in's deployment centralized.
Has anyone pulled this kind of install off successfully?
I've deployed VSTO from SCCM without using an MSI.
The trick is a simple command line:
"%commonprogramfiles%/microsoft shared/VSTO/10.0/VSTOInstaller.exe" /i <path to vsto>
VSTOInstaller.exe [[/install ] | [/uninstall ]] [/silent]
[/help]
/install, /i: Install the solution. This option must be followed by
the fully qualified path of a deployment manifest in the form http://,
https://, or \servername\foldername.
/uninstall, /u: Uninstall the solution. This option must be followed
by the fully qualified path of a deployment manifest in the form
http://, https://, or \servername\foldername.
/silent, /s: Install or uninstall without prompting for input or
providing information.
/help, /?: Generate this help message.
EXAMPLE: VSTOInstaller.exe /i \servername\foldername\AddIn.vsto
Be aware that with the /silent option "trust for the addin has to be built into the project or it will default to 'don't install' when using the silent switch." (source: TechNet post)
I've tried it, and you don't need to wrap it in an MSI if you're happy for users to manually install it. If you:
use the publish tab in project -> properties
setup your "publishing folder location" and "installation folder URL" properly
set and all of the other meta-data properly, including stuff in your AssemblyInfo.cs file
whack the "publish now" button
share out the installation folder and email out the link
ensure that users have the right permissions to install it (local admin I guess, you'd need to check)
It worked for me. On Windows 7 and XP too.
The whole "this publisher is untrusted" thing is a complete mess, trying to fix that involves writing some really stupid code that tells Windows that "hey, by the way, I am actually trusted". I didn't bother and just told people to ignore the warning.
I'm guessing that you only need an MSI if you want to push out the add-in using active directory and do an automated install.
I am having a problem with a Wix installer, that covers three different feature sets (Client / Developer and Server).
When Client is selected the installer does not need to perform any of the actions with IIS that are defined in components that aren't included within this feature.
On Installation I don't get a problem, as I have added a Custom Action
<!-- Only perform the IIS Configuration if we have installed the Admin Application-->
<Custom Action="SkipIISCA" Before="InstallValidate">
<![CDATA[COMPONENT_TYPE = 2]]>
</Custom>
Which is only run when the "Client" component type is being installed. The custom action sets the SKIPCONFIGUREIIS property to 1
The problem occurs when either a Repair on an uninstall is executed on the installer. It appears that IIS Configuration is being attempted when the product is being uninstalled or repaired, and the custom action does not seem be run to disable this behaviour.
Is there a good way to set the SKIPCONFIGUREIIS setting on uninstallation / repair based on a Registry Setting ?
Thanks.
Some of the properties set during an installation are stored in the hidden windows directory, c:\windows\installer - one per installation. In the log of your uninstall/repair session, you can see that cached file opened up and properties being set for the new uninstall/repair session. (Alternatively, you can find this temp file from the uninstall/repair log, and open it with Orca. In Orca, under "Property", it will show the values of any install properties saved).
Based on the above description, I bet that the property that the custom action is being set is not stored, but that the value of COMPONENT_TYPE is available (The same input that was used to set SKIPCONFIGUREIIS in the custom action).
If so, then just make the IIS configuration action be based on these properties:
<Custom Action="Your_Configure_IIS_Action" Before="InstallFinalize">
(NOT SKIPCONFIGUREIIS ) OR (COMPONENT_TYPE = 2)</Custom>
If you don't want the ConfigureIIS to happen for any feature set during uninstall/repair, then just use these properties:
<Custom Action="Your_Configure_IIS_Action" Before="InstallFinalize">
(NOT UPGRADINGPRODUCTCODE) AND (REMOVE="ALL")</Custom>
Another thing to think about is if the original installer was at one level - e.g. a client, and the uninstall/repair is being done by someone at the server level. The component_type of the original install is stored. In that case, you might consider adding a check on how the component_type is determined (thru a dialog or some other attribute) during the uninstall/repair.