Is it possible to initiate a silent installation of a WiX bundle through the use of a command line argument in the format of /a or /arg?
I'm aware of the available command line arguments accepted by the wixstdba bootstrapper.
Specifically, we need to do this using the argument /s /v/qn argument.
NB: Executing the bootsrapper with the command line setup.exe /s /v/qn actually does initiate a silent install, and I assume this is because the BA interprets the /s as equivalent to -s. But since I can't find this behaviour documented anywhere, I am nervous about relying upon it, and would prefer an explicit method for doing this.
TL;DR
The reason we would like to support this argument /format is due to the automatic upgrade operation of a previous version of the software. This version of the software launched an automatically downloaded upgrade to itself, which was an InstallShield package, with the switches /s /v/qn to launch the MSI as a silent installation. Those switches are coded into a constant field, so the fact that we are moving from InstallShield to WiX presents this problem.
We would like to replicate this functionality but need a way to translate this set of arguments to either a -silent or -passive argument, or find some other method to accomplish this task.
Burn supports both - and / as switch characters. Silent UI mode is supported as q, quiet, s, and silent with leading - and /. See the code at https://github.com/wixtoolset/wix3/blob/develop/src/burn/engine/core.cpp#L1098.
Related
I will try to explain the issue by example. I have mypackage-v1.0.msi and mypackage-v1.1.msi. Both packages when installed silently expecting PASSWORD parameter:
msiexec /i mypackage-v1.0.msi /qb PASSWORD=SomeThing1
mypackage-v1.0.msi is already installed and mypackage-v1.1.msi should upgrade mypackage-v1.0.msi. There is a custom action in both packages that depends on this parameter but because of the issue with conditioning this custom action in mypackage-v1.0.msi, during upgrade it is executed but the PASSWORD parameter is not transferred to it.
I wonder if there is a way to patch mypackage-v1.0.msi before upgrading to mypackage-v1.1.msi. But the patch is not changing any contents of installation but the package itself. Is it possible?
Edit:
More focused input - is it possible with the patch to replace a condition for InstallExecuteSequence custom actions?
Yes. Patches include transforms, which modify packages. In fact, patches always modify tables in the package, even when they don't change content of the payload files.
The comments above became too messy. Here is a quick re-write as a regular answer:
Minor Upgrade: A minor upgrade can change most things in an installed MSI package before its uninstall or upgrade sequence is called. It can hence fix problems relating to major upgrades or failed uninstalls among other things (you fix the uninstall sequence before it is invoked).
Sample: Here is the simplest sample of a minor upgrade I could find at the moment (another sample from FireGiant's documentation).
For the simple sample: open the CreatePatch.cmd and update path to WiX binaries (likely ending in v3.11 at this point in time: set wixDir="C:\Program Files (x86)\WiX Toolset v3.11\bin\").
Keep in mind that a minor upgrade has many limitations. Keep things simple and change only what you need to fix your problem.
Minor Upgrade Details: The table at the bottom here shows what needs to change for a minor upgrade. Essentially package code and product version + plus whatever change you want to implement. The above link is to InstallShield's documentation (a different MSI tool), but this is a generic MSI technology concept - it is not vendor specific.
You can deliver the minor upgrade as a new MSI or as a patch file (*.msp). For an MSI you need to use a special command line to install. Something like this:
msiexec.exe /i MySetup.msi REINSTALLMODE=vomus REINSTALL=ALL
The v tells msiexec to re-cache the MSI so that it updates the existing cached one "in-place".
REINSTALLMODE documentation.
Applying Small Updates by Reinstalling the Product.
Links:
https://support.firegiant.com/hc/en-us/articles/230912367-Upgrade-options
https://www.firegiant.com/wix/tutorial/upgrades-and-modularization/
I've added the following to my WIX template to prevent installation without entering values in a custom dialog i've made.
<Condition Message='This installation can only run in full UI mode.'>
<![CDATA[UILevel = 5]]>
</Condition>
When I try to uninstall the application I get this message, and I'm unable to proceed.
How do I fix this so that it does not apply on uninstall?
How can I forcibly uninstall this application?
Question 1: LaunchCondition
LaunchConditions must always evaluate to true for the setup to be able to install / run. There are some further details here: Failing condition wix (recommended for more context). When you invoke uninstall via Add / Remove Programs it will run the installer in silent mode (I believe UILevel = 2 or UILevel = 3), which fails your LaunchCondition since UILevel is not equal to 5.
OR Installed: A common technique to prevent LaunchConditions to trigger problems in other installation modes than fresh install, is to add OR Installed to the LaunchCondition in question. This will force the LaunchCondition to be true for all situations and modes where the product is already installed (modify, uninstall, repair, etc...).
So something like this could probably work as an updated condition:
Installed OR UILevel = 5
Wrong Approach?: With that said I would rather implement a check to determine if the value you need specified has been set on the command line via PUBLIC properties for a silent install, instead of that rather strange LaunchCondition checking the setup's GUI level. You can still implement this as a LaunchCondition - or use a custom action for more flexibility. The LaunchCondition would check for values for all critical setup parameters, and you would prevent them from running on uninstall and other modes with the OR Installed mechanism. Here is an answer on the topic of silent installation, transforms and public properties: How to make better use of MSI files (silent deployment is crucial for corporate deployment and software acceptance).
Question 2: Forcibly Uninstall
UPDATE: A couple of additional options listed towards the bottom for completeness.
2.1 - ARP Modify: I want to run the simplest option by you before going into too much crazy detail. Is the Modify option available for your setup in Add / Remove Programs? If so, please click it and see if you then can select remove from the setup's Modify dialogs. This should work (since you are generally not running the setup in silent mode when choosing Modify).
2.2 - Interactive msiexec.exe Uninstall Command: I forgot to add that you should be able to kick off an interactive uninstall via command line as follows: msiexec.exe /x {PRODUCT-GUID} /qf. Here is how you can find the product GUID: How can I find the product GUID of an installed MSI setup? So in summmary: you find the product GUID as explained in the link, and then you open a cmd.exe window and fire off the uninstall command indicated above.
2.3 - Microsoft FixIt: If the first option above is not available, there are several other options that could work, but before trying them I would recommend giving the Microsoft FixIt tool for installation / uninstallation problems a chance to see if this does the trick for you. Run it, select your installation and see if some auto-magic is there for you to get it uninstalled.
2.4 - Advanced (avoid if you can) - hack system-cached MSI: This answer will be the next step, if the above fails: I screwed up, how can I uninstall my program? Please let us know if the above does not work, and we will check the options here. I would just zip up the cached MSI and disable the launch condition, but this is way too hacky for comfort if you can avoid it.
UPDATE: The below was added, but not needed to solve the problem. It is not recommended, it is the last resort. Leaving the content in.
Finding Cached MSI: you can find the system cached MSI using Powershell as explained here. I will inline the Powershell command here:
gwmi -Query "SELECT Name,LocalPackage FROM Win32_Product WHERE
IdentifyingNumber='{PRODUCT-GUID}'" | Format-Table Name,
LocalPackage
You then open the cached file (make a backup of it first, or zip it) with Orca or an equivalent tool, and you make whatever change needed to get the uninstall to function correctly. This is not generally considered a sane approach - it is the last resort. And what you change in the MSI is different depending on what is wrong with it. This requires specialist MSI knowledge. It is easy to mess things up so uninstall becomes even more difficult.
I just saw you got the product uninstalled whilst writing this. Puh! Be glad you don't need this latter approach. I think I will commit it and set it to strikeout so it is visible but not recommended (if only for myself to reuse if needed).
UPDATE, some additional alternatives (not always applicable, included for reference and potential re-use): 1) If you have access to the original MSI used to install your software (it must be the exact copy of the MSI used to install), then you can try to double click it and this should take you into modify directly. 2) You can also double click the file in the system cache folder if you no longer have the original installation MSI. 3) It might be you can hotfix the uninstall string in the registry as well to force a non-silent uninstall:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall
HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall
There are probably further ways. For example 4) hack a transform to apply during uninstall, 5) patch the installed MSI (if it is in the wild with lots of installs everywhere), etc...
I want to execute the below lines of code through WIX and here is the code where am able to do it through the command prompt:
dism.exe /online /enable-feature:NetFx3 /quiet /norestart -----> To enable
dism /online /get-featureinfo:netfx3 ------> To verify the value
If all that you want to do using Wix is to launch executables, Wix/windows installer provides multiple ways to do that.
I generally prefer using Quite Execution custom actions provided by the Wix toolset. Reason being, it allows me to launch executables without displaying any console windows, which otherwise would have required me to write custom action code.
Take a look at :
http://wixtoolset.org/documentation/manual/v3/customactions/qtexec.html
The examples in the above URL are sufficient enough to help you get started.
In order to use QtExec (Quite execution custom actions), you must include a reference to the WixUtilExtension when building your MSI. To do this, add the command line argument -ext WixUtilExtension.dll when calling Light.exe.
I've created an installer using wix 3.6 which produces an msi file that includes several dialogs (EULA, install location, etc). I then create a self extracting zip file using WinZip Self Extractor in the "Software Installation" mode which kicks off the msi. All this works great.
However, some users have requested a "minimial" install mode that doesn't prompt for input, it just uses all the defaults and installs. This would be used for admin type installs as part of a larger install script. I can pass /qb to the msi and get the exact behavior they want, but if I pass /qb to the self extractor exe it doesn't pass it along to the msi like I want. I've looked through the WinZip Self Extractor documentation, but haven't found an answer. Any ideas on how to make this work?
I don't recommend using generic self-extracting executables like WinZip and others because they do not cache the MSI file. Future operations with the MSI including minor upgrades, patches, and repair may require the MSI to be provided with the name the self-extractor used (hopefully WinZip doesn't change that) and will default to the path (usually %TEMP%). Users are often very confused when this happens and can't upgrade or fix their installation.
Instead, I recommend using a Bootstrapper/Chainer designed to install packages. WiX v3.6+ comes with a new feature called Bundle that uses the new Burn engine to handle all the self-extracting scenarios, plus much much more. It takes a bit more work to get created up front but can behave exactly like you are asking in this question.
Probably not the answer you were looking for, but I highly recommend considering using a real bootstrapper/chainer instead of a self-extractor.
I am trying to silently install apache using Advanced Installer 8.9, but it is still prompting me for user interaction even though I pass the command parameters in the Silent (No UI) field.
msiexec /i "httpd-2.2.22-win32-x86-no_ssl.msi" /qn /passive ALLUSERS=1 SERVERADMIN=admin#localhost SERVERNAME=localhost SERVERDOMAIN=localhost SERVERPORT=80
What can I do to solve this?
The parameters set in "Silent (No UI)" field are used by the prerequisite only if the bootstrapper is running with silent UI. If you want these parameters to be used for all the UI levels of the bootstrapper you need to set the same command line in all fields, i.e. Full UI, Basic UI and Silent (No UI).
Agree with #bogdan. Also, I noticed that you pass the entire msiexec command into the parameters. If you have specified apache as a prerequisite, you only need to pass the arguments of msiexec in the command parameters, e.g. /qn, /passive etc. You shouldn't pass "msiexec" as command line parameters.