I've googled this to death and cannot find a solution that works.
We need to prevent the user from re-installing our app while it's still running. The standard FilesInUse dialog works but it still allows the user to continue while the app is running and we dont want to force them to reboot - ie, they have to shutdown the app manually.
We tried to create a custom FilesInUse dialog:
We include the FilesInUse source and remove the Ignore option
Rename the ID of the dialog
Change the DialogRef in the Mondo UI
Add an suppress for ICE20 because it complains the FilesInUse doesnt exist if we dont do this.
The new dialoag is never used.
If I leave the id of FileInUse unmodified then I get an error about a duplicate dialog.
Ive also tried using utils:CloseApplications but this never does anything.
So: What is the current thinking on how to do this?
Thanks
PS, I love Wix but it does frustrate me at times :) Much like the wife...
Looking to achieve the same thing, I discovered the answer in the related question: Including modified FilesInUse dialog in WIX project.
Remove the DialogRef entry of FilesInUse from the UI file, and replace it with the custom Dialog for FilesInUse directly in the UI file.
Related
I was trying to change the default MsiRMFilesInUse dialog box provided by restart manager used in wix toolset. Basically I want to localize the default message in the dialog box since it is not getting localized by windows.
I found this answer (https://stackoverflow.com/a/46462452/14162315) which explains the steps of making the custom dialog box instead of normal one. A custom dialog box could help me in localizing the message.
I tried the above steps but I am getting the error - Duplicate symbol 'Property:WixUIRMOption' found. This typically means that an Id is duplicated. Check to make sure all your identifiers of a given type (File, Component, Feature) are unique.
I thought that I have to change the property id of WixUIRMOption also to some custom value to mitigate the error, so I changed it to Custom_WixUIRMOption. It compiled successfully after this change but the dialog box is not coming at all after this change.
link to source code of default MsiRMFilesInUse.wxs - https://github.com/AnalogJ/Wix3.6Toolset/blob/master/RC0-source/wix36-sources/src/ext/UIExtension/wixlib/MsiRMFilesInUse.wxs
you should be fine if you provide a localization for MsiRMFilesInUseText.
<String Id="MsiRMFilesInUseText" Overridable="yes">Translated text</String>
See how the dialog is implemented:
https://github.com/wixtoolset/wix3/blob/develop/src/ext/UIExtension/wixlib/MsiRMFilesInUse.wxs
See how wix ui is translated:
https://github.com/wixtoolset/wix3/blob/develop/src/ext/UIExtension/wixlib/WixUI_en-us.wxl
I have created a custom UI and provided the standard dialog boxes as required to avoid ICE20 errors. I have included the following line as required:
If I use a WIX UI this works fine. But now I've created my own custom UI I get an "unexpected error" message with error code 2814 and then one with 2869. Does anyone know how to catch the attempted downgrade to produce a dialog box with the correct message?
I am not an MSI dialog expert, but there are a few things I can point out:
You can customize the internal GUI built into an MSI.
You can also make your own GUI for Burn setup.exe launchers.
Burn GUIs can be more modern than the rather ancient MSI GUI.
A Burn launcher can hide the built-in MSI GUI during installation.
I am not sure what GUI you have customized?
Error 2814: The error code 2814: "On the dialog [2] the control [3] names a nonexistent control [4] as the next control." - this seems to indicate that a control on your dialog points to a non-existent control as the next one to go to for the TAB order of the dialog. You need to point to a valid control that exists and it should be visible too.
Custom MSI GUI: Making your own MSI GUI is rarely advisable unless you need something very specific and unusual. You can use existing dialog sets and just inject a new dialog (which might be what you have done). Due to the lack of flexibility for MSI dialogs I would recommend that you make a Burn setup.exe GUI if you really need a lot of flexibility. I have not looked at this a great deal.
WiX MSI Dialog Sample: There is a sample, modified WiX MSI dialog set here: https://github.com/glytzhkof/WiXCustomDialog
Links: I have a few links on MSI dialogs and Burn GUI. This is quite overlapping, please just skim and see what makes sense to you:
WIX Installer with modern look and feel
Changing text color to Wix dialogs
Wix default folder dialog
Removing Default dialogs from MSI
Other Links:
A very clever effort from Stefan Kruger to work around the MSI GUI dialog limitations: http://www.installsite.org/pages/en/msi/articles/MultiListBox/index.htm
Dynamically changing RTF content in the EndDialog after success
https://github.com/frederiksen/Classic-WiX-Burn-Theme
How to add image background to custom MSI dialog?
If I find an issue from within my Custom Action checks (user chose a bad install directory in the WixUI_InstallDir dialog), after I let the user know of it (by using the _session.Message), can i somehow go back to that page in the wizard (the one that shows the install dir dialog)?
Right now I just return a ActionResult.Failure which is not ideal since he'll need to run the MSI all over again.
Update: I just noticed that when I return ActionResult.Failure, i'm still in the wizard with the "... wizard ended prematurely" message. The Finish button is enabled but the Back is not. Can I somehow change that so that the Back is also enabled? That would solve my problem.
Thanks.
Don't return a failure. Instead, set a MSI property (e.g. VALID_INSTALLDIR) to 1 or 0 based on your validation requirements. Then, condition the 'Next' button's SpawnDialog event on VALID_INSTALLDIR=1. This will keep the user from advancing to the next dialog until they choose a valid install path.
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.
I'm using WIX to create an installer and WixUI_Mondo for the UI. Everything had gone well until I stumbled upon a problem with MaintenanceTypeDlg. Things work finely when I install the application, however when I click the MSI later on (when the app is installed), I get change/repair/remove buttons grayed out.
Here are relevant parts of my installation project (sorry, didn't manage to put them inline, since they got cut by the forum software, so had to upload them to pastebin.ca): http://pastebin.ca/1958654.
So, as you see, I'm setting ARPNO*** properties to zero, and, what's more, the log shows these properties set to zero during install. I've also tried to swap include directives, so that UI goes after ControlPanel - unfortunately, with no luck. Any ideas about what am I doing wrong? Thanks in advance.
Don't set the ARPNO* properties; as the documentation says, "setting them" -- i.e., to anything -- disables the ARP behavior.