i have sucessfully installed my msi in silent mode using the following command. msiexec /i mysetup.msi /qn. Also, i have a custom action in my installsequence which is a gui for some configuration. And i dont want that gui appears while installing in silent/command line...
If running in completely silent mode, the "UILevel" property will be equal to 2. Check out this reference for the different levels of UI.
To apply it to your WIX project, in the Sequence you're running the Custom Action, add a condition for the property so your EXE isn't run if that is true. Something like this:
<Custom Action="CA_GUIConfig" After="SetUILEVEL">Not UILevel="2"</Custom>
It may be that the property you need to use in your condition is CLIENTUILEVEL, but it's UILevel that's being checked in my custom code (it's been 10 years since I wrote it, so I'm not exactly clear now). Between either of those 2 properties, I think you'll get it.
Related
I made an installer using wix burn.
I used the standard bootstrapper with Hyperlink license theme.
I don't want to display the EULA checkbox on upgrades. Once accepted one time, I don't want to show it again, or at least auto select it.
To achieve that, I customized the bafunctions.dll and wrote some code in OnDetect(). After a given condition is match, I set the variable EulaAcceptCheckbox = 1. I know that this is the variable name corresponding to the EULA checkbox because I inspected the log of the installer before making this changes.
After making all the modifications, I know my logic is working because I see the following lines in the log:
[1510:1410][2015-11-17T19:01:04]i000: Running detect complete BA function
[1510:1410][2015-11-17T19:01:04]i000: Setting numeric variable 'EulaAcceptCheckbox' to value 1
But the checkbox is not displayed as checked. I tried to set 'EulaAcceptCheckbox' in OnDetect() and also in OnDetectComplete(): no luck.
I also tried to set LicenseUrl="" and WixStdbaLicenseUrl="" but that does not work either.
I have already used bafunctions.dll to do some checkbox customization in another installer. It seems not to work with the EULA checkbox only. What's wrong with my approach?
There seems to be no solution for this.
I need to add a dialog box that would pop up during complete uninstall (not major upgrade) right after the confirmation ("Are you sure you want to uninstall this product?") dialog. This dialog would prompt the user to answer a question and based on the response, set up a property that would be used in the condition for the RemoveRegistryKey element (i.e. it will remove a registry key only if the user selects an option to delete the key).
I have an idea how to add a dialog to the install sequence (I am using a modified WixUI_InstalLDir sequence to which I added a custom dialog I need during installation), but I can't find any references that would explain how to add a custom dialog to an uninstall sequence. It would be even better if I could modify the uninstall confirmation dialog, so the user would see one dialog instead of two. An the key thing would be to be able to set up a property that could be used in the component condition.
Is this possible? Are there any examples how to do this?
This is against Microsoft design guidelines. Add/Remove programs calls the uninstall with a silent UI argument and the UI sequence is never processed.
The only place you can author UI during an uninstall is a "change" or "maintenance" UI experience where they select Repair | Change | Remove and on Remove do your UI. But you'd have to lock down the Remove buttom and force them through this path. Also realize they could call msiexec /x /qb from the command line.
Bottom line is Microsoft made this choice to make the uninstall process simple and easy for the user. As for removing the registry key, Microsoft would say that you should leave user data on uninstall.
We have an MSI and Bundle created in Wix. I need to localize both of these in such a way that language selection GUI will be popped-up and language can be selected by the user at run time. Would be really appreciated if anybody can help me on this.
For MSI, i am working on creating another bootstapper for bringing-up with language selection combobox and invoke the tranfomed MSI with the required transform(using command shell). I am still not sure about the feasibilty of this approach. I am facing issue in creating combo box in customized UI of bootstapper and invoking batch command to run this msi in the required language.
For Bundle - I am still working on finding a method. if anybody has any idea/samples for this.
It will be helpful if anybody can help me with this issue or provide me with an another alternative method to meet above requirement.
Thanks,
The recommended method (and for that matter, the method used by most MS products), is as you describe.
Create an MSI localized for each language
pick a base and generate MST's
Package the MSTs, the MSI and the bootstrapper, which will
present the language selection dialog and call MSIEXEC, passing TRANSFORM=language.mst as an argument
After the MSIEXEC process has started, all localization is finalized, so to speak. Any selection must go on outside the MSI system.
See this codeproject article for an example.
I guess this may help you:
creating language selection dialog using WiX.
there is a limitation that custom UI for language selection is created using C# based custom bootstrapper. This may lead to the requirement of .Net framework on host machine.
UI selection for MSI
Create an MSI localized for each language
Pick a base and generate MST's
Package the MSTs, the MSI into a bootstrapper.
Customize the HyperlinkTheme.xml to include radio button for selecting each language.
Use the Variable tag to link radio button from UI to .wxs file
Include the msi property in the msi tag and hard code the path to MST's and InstallCondition attribute to differentiate each selection
Use the latest version of wix for this feature support.
Bundle support only automatic base detection there is no support for UI selection
I have 3 Installers which install different products. I need to create shortcut for every product like this
Start->Programs->CompanyName->Product 1
->Product 2
->Product 3
How to do this?
Also, I'd like to remove CompanyName folder during uninstall if it is empty. i.e. one from un-installers must remove it if it is empty.
If you are having problems with orphaned shortcuts during the uninstall process of any of the three installers, you might be using the same GUID for the shortcut component or others.
This will cause the installer to disallow the uninstall of the component because it is in use for an other client(application installed) if you look at the logs you will find this message :
Disallowing uninstallation of component: {GUID_ID}
Following the instructions of the Wix Manual in the previous answer, you should not have any trouble creating the shortcuts you want and the behavior you want as well.
I have an msi (authored with WIX) that has a check box bound to a custom property (call it MY_PROPERTY). I would like to run this msi from the command line, specifying 0 (unchecked) or 1 (checked) for this property. My script will determine the appropriate value (based on the environment) and inject that value into the msiexec command line. My command line looks something like this:
msiexec /i my_installer.msi MY_PROPERTY=$value
Where $value is 1 or 0, depending on the environment. The problem is that no matter what value I supply for MY_PROPERTY at the command line, the check box is always checked (and the property will always be set to 1). The only way to make the checkbox unchecked is to not specify the property (leave it undefined). It should be noted that this behavior occurs regardless of whether or not the UI is showing (adding "/quiet" to the above command line doesn't change this behavior).
This msdn post seems to indicate that this is a known "bug" in windows installer (or more accurately, whatever authoring system wrote the msi). A post-build msi hack is proposed as the solution. I'm wondering if anyone has encountered this issue and come up with a better workaround/solution. Thanks!
Update
I see three solutions to this problem:
From #Damien, have the wrapper script not pass the property to msiexec when its value is 0. This makes the script more complex and would probably prevent me from being able to override the value of a check box that defaults to "checked".
From #Michael Urman, add a custom action that clears the property if its value is zero. This makes the msi more complex, and I would have to add such a custom action for every check box in the UI.
Another idea is to simply disallow the use of check boxes in our msi installers, and use radio boxes or drop-downs for "true/false" questions instead. While this restricts the UI options for our installers, it woudl allow the wrapper scripts to remain simple, and does not require custom actions to "hack" the properties.
I'm currently leaning towards option 3, although option 1 is probably the best answer to my original question. Any thoughts?
This is how it is "supposed" to work - basically, the property doesn't exist until a user checks the checkbox, then it is "set" (exists). So if you want to do a custom action when a checkbox is checked, you test for the existence of the property as a condition for running the custom action, instead of checking for the value that the custom prop is set to.
I think the best way to handle this from the command line is what you have already mentioned: if you want the checkbox to be selected, specifiy the custom prop on the command line, otherwise, don't and the checkbox will not be selected.
As you've discovered, checkboxes are true (checked) when the property is defined (non-blank) and false (unchecked) when the property is undefined (blank). It sounds like you need to convert an environment 1 or 0 string to a checkbox true/false, where the 1 or 0 is passed in at the command line. Try using a set-property custom action that sets your property to {} (blank) with a condition of when the property is already "0". Schedule it early in both the Install UI and Install Execute sequences.
Late Update: Regarding the need for multiple custom actions to handle this for multiple checkboxes, you have a choice. You can either create multiple set-property actions (benefit: easy to tell what they're doing; cost: many of them), or you can create a single code-based custom action which walks the Checkbox table for a list of properties to convert from 0 to blank (benefit: one action; cost: poorly documented, custom code). A secondary advantage to the latter approach is that you can handle unusual Value settings, such a check box that should set the property to 0 when checked.