I have a WiX Bootstrapper that invokes MSI. If I launch it as:
setup.exe
It will show a UI and user must process with the installation manually. However, if user passes passive property, the installation will begin automatically. Uninstallation can also be done silently (no UI interaction required) with:
setup.exe -uninstall -passive
What I want is to enable passive-ness by default. I have tried using Variable in Bundle as:
<Variable Name="passive" Type="string" Value="true"/>
But doesn't have any effect (even with value set to "1", or "yes").
Further, I have tried to set MSI property in Chain->MsiPackage:
<MsiProperty Name="passive" Value="1"/>
It doesn't make the installation passive by default.
What could be done?
I am using WixStandardBootstrapperApplication.RtfLicense UI mode.
passive isn't a property; it's a switch. WixStandardBootstrapperApplication does not support passive UI by default. You'd have to write your own bootstrapper application to do that.
Related
I have a installer which asks the user to select feature. Whatever user selects, it will never be changed in case of modify and upgrade the installation. For example:
There are three features in my installer which are below:
<Feature Id="Standalone" Title="Standalone" Level="2">
</Feature>
<Feature Id="CentralCase" Title="Central case" Level="2" >
</Feature>
<Feature Id="MiddleEF" Title="Middle Ef" Level="2" Display="expand">
<Feature Id="GUI" Title="Client" Level="3"></Feature>
<Feature Id="AppServer" Title="Application Server" Level="3">
</Feature>
</Feature>
Now suppose user starts the installation and select the first feature which is standalone and install it. Now if user wants to modify, he should not allowed to change feature or even if user wants to upgrade, user should also not allowed to change feature. He can only upgrade what he selected at first time. Is there any way to do this?
ARPNOMODIFY: I guess it depends how critical it is that these features never change. You can set the ARPNOMODIFY in the MSI to
1 and there will be no button to invoke Modify from:
<Property Id="ARPNOMODIFY" Value="1" Secure="yes" />
Disclaimer below. Here be dragons.
msiexec.exe: However, you can still invoke modify by launching the MSI file itself (the default dialog sets should correctly disable the modify button though), but worse: you can go via the msiexec.exe command line and change anything you want:
msiexec /i "MySetup.msi" ADDLOCAL=MyFeature
This might be OK since it would appear to be seldomly used. However, you should be aware that remote management systems often rely on the msiexec.exe command line to handle MSI deployment, and as such the deployment system could be used to change feature state easily (via the deployment tool GUI, no command lines to deal with).
Custom Action: I don't know of an auto-magic way to abort setup if the user tries to modify the feature structure invoked via the msiexec.exe command line, but I suppose you can use a custom action maybe right before InstallInitialize in the InstallExecuteSequence to abort the installation if ADDLOCAL, REMOVE or ADVERTISE are set? If you do not condition this custom action properly, it could cause a package that won't uninstall at all or upgrade properly.
Some unverified conditioning suggestions: How to execute conditional custom action on install and modify only?
MigrateFeatureStates: For a major upgrade the GUI will not run as if it is running modify, but a fresh installation (since the product GUID is new). Hence the original installation GUI is shown and not the modify one. Accordingly you might need to disable some GUI controls or hide whole dialogs to prevent feature selection (not sure in WiX default dialogs). Added a link for that below. The standard action MigrateFeatureStates will take care of preserving the feature installation states between versions, provided you haven't done anything drastic to the feature structure. You enable this standard action to run in the Upgrade table. Should be default to run in WiX MSIs I think.
UPDATE:
Preselected Property: There is a special property called Preselected that is to automatically hide feature selection. You can try to set it or check whether it is set automatically by WiX to see if it hides feature selection. I have honestly never tried it.
Some Further Resources:
Hiding whole dialogs: Wix, custom dialog when previous version exists
In my company I create apps that are shared by many different products. For instance a help application.
A requirement is that I create an MSI with WiX that can be consumed by the main installers for each product. This MSI receives variables from the main installers so that it installs and uninstalls properly.
Because of this, I want to restrict having the MSI run by itself. That is, someone double clicking on it, etc.
Is there a way I can prevent it from running on its own and display a message of some type to the user?
I am completely new to WiX and I really appreciate your help.
You can set a public property which blocks the installation of the product by default - i.e. if a user were to attempt to install it by double-clicking.
<Condition Message="test">BLOCKINSTALL = 1</Condition>
<Property Id="BLOCKINSTALL" Value="0"/>
This blocks install by default. The property can then be changed by your other installers, or by calling:
msiexec /package Installer.msi BLOCKINSTALL=1
This will allow you to change the blocking value, allowing the installation to progress.
I have written an msi which deals with registry. So, i have to run the msi as admin.
when i directly click and launch the Msi,I get the following error to modify the ini file "Access to the path is denied"
It works fine if i launch the msi from command prompt(Right click as administrator.)
I tried all the below suggestions but none of them is working. please assist how to run msi as admin.
Package Id="*" InstallerVersion="200" Compressed="yes" Platform="$(var.Platform)" InstallPrivileges="elevated" AdminImage="yes" InstallScope="perMachine"
CustomAction Id="UpgradeSelectedVersion" BinaryKey="CustomAction" DllEntry="UpgradeSelectedVersion" Execute="deferred" Impersonate="no"
Property Id="ALLUSERS" Value ="1"
or
Property Id="ALLUSERS" Value ="2"
Try the following:
<Property Id="MSIUSEREALADMINDETECTION" Value="1" />
Otherwise, you could wrap your installer in a wix managed bootstrapper application, a bit more work though. Then you add settings to your manifest file.
That custom action is deferred, which means it must be running in the InstallExecuteSequence, which should be elevated and running with the system account if you have InstallScope per machine and elevated privileges.
Don't mess with the ALLUSERS property because WiX just does the right thing. InstallScope per machine and elevated privileges will make it work. If you accidentally turn it into a per user install by messing with ALLUSERS then it will not be elevated and it will fail.
You should be seeing a UAC elevation dialog after the UI sequence. If you are not seeing this dialog then the install will not be elevated. Again, that might be related to you changing ALLUSERS. If you are installing this in silent mode then it will also fail because silent really does mean silent, and it will not show the elevation dialog and your CA will not run elevated.
It's possible that your failing custom action is not the one you posted, which is deferred and therefore after the elevation prompt. If you have a custom action in the UI sequence then it will not be elevated (unless you run the MSI from an elevated prompt) so that may explain the issue you are seeing.
I'm trying to create an installer that supports perUser and perMachine installations dependent on a selection of setup types on the UI.
The perUser setup type installs the application into "WIX_DIR_COMMON_DOCUMENTS" and shall require no admin permissions.
The perMachine setup type install the application into "ProgramFilesFolder" and shall request an UAC dialog.
My attempt was to initially set the Package/#InstallScope to perUser and then modify the ALLUSERS property later on.
If the user selects the perMachine setup type I'm trying to set the ALLUSERS property to 1 doing the following:
<Publish Property="ALLUSERS" Value="1">1</Publish>
The "Install" buttons gets an UAC icon, but no UAC dialog appears after I pressed it!
Instead I get an error message that I obviously have no privileges to install the application for all users of the machine.
Is it a bug that no UAC dialog appears or intended? Am I missing something?
Someone from the WiX Mailing list pointed me to the Single Package Authoring article on msdn.
I had to initialize the following properties:
<Property Id='ALLUSERS' Value='2' />
<Property Id='MSIINSTALLPERUSER' Value='1' />
and set the 'MSIINSTALLPERUSER' property to an empty string for a per-Machine installation.
<Publish Property="MSIINSTALLPERUSER" Value="{}">1</Publish>
Be aware that this only works for Windows Installer 5 and higher!
My question is quite similar to
Launch application after installation complete, with UAC turned on
Rather than build a complex set of configuration screens into the installer, we would like to launch a config process after the installer is complete.
In all cases this will require the editing of content in ProgramFiles folder which is not editable as a standard user when UAC is enabled without elevation.
Options we know of and prefer not to use:
to elevate the whole installer with a bootstrap - we would like not to do this to support 1 action of execute the config at the end elevated.
including forced elevation in the config process - while we could in some cases work this into the app, in some cases we want to launch a simple editor on App.config where this forced elevation would not be an option.
Is there some way of getting an elevated version of
<Property Id="WixShellExecTarget" Value="[INSTALLDIR]\app.config" />
<CustomAction Id="LaunchApplication" BinaryKey="WixCA" DllEntry="WixShellExec" />
Or is it more appropriate to make custom UI and add the checkbox earlier in the UI and launch it as a deferred action without waiting, like
<CustomAction Id="Config.SetProperty" Property="Config" Value='"Open" app.config' />
<CustomAction Impersonate="no" Execute="deferred" Return="ignore"
Id="Config" BinaryKey="WixCA" DllEntry="CAQuietExec" />
Or do we just forget it all as a bad idea and the admin can go find the file and right click elevate to edit.
One of the options could be to launch your app non-elevated from the installer as you do now. Then when your app detects that it needs to edit config files, and it requests elevation.
Another option is to store config files in ProgramData directory rather than in Program Files. This location is writable without elevation. One caveat here: files and directories that created there will have write/modify permissions only for the user who created them; other users will have read-only access. If it's not desirable, you can change ACLs for your app config files.
I suggest a separate config tool, that requires elevation for all-user config and continues with per-user config if elevation is denied.
Launch this on completion of installer (from the UI sequence only, tie it to the 'Finish' button) so that normal installs launch and prompt for elevation on completion while silent installs require the Admin to manually launch the configuration tool or edit the config file themselves.
Note that if you're installing the config file as an MSI component, if it has been edited then an Advertised shortcut or running a Windows Installer 'repair' will overwrite this with the one included in the MSI. Our general solution has been to deploy a sample.config and require the administrator to edit copy this to an application.config post-install. If the application.config is not present, the configuration tool launches or an error message displays. This has the added benefit that the configuration is preserved on remove/upgrade.