I'm updating an InstallShield based installer. I've added a new managed custom action, written in C#, and packaged using Wix DTF.
Action is invoked correctly, and performs necessary actions.
Problem I have is showing an error message to user.
Method 1: MsiProcessMessage
From articles I've read, I understood that MsiProcessMessage is the correct way to do it, however this method does not work in UI sequence (before setup actually starts copying files and modifying system). In install sequence this method works. Code which I use is following:
Record record = new Record() { FormatString = "Password is not valid for this user." };
session.Message(
InstallMessage.Error | (InstallMessage)(MessageBoxIcon.Error) | (InstallMessage)MessageBoxButtons.OK,
record
);
Is it actually impossible to show an error message in UI sequence (Immediate execution) using MsiProcessMessage?
Method 2: MessageBox.Show
Using Windows.Forms works for showing a message box. However, message is displayed in background of setup wizard, and shows a separate icon in Windows taskbar.
Is there a way to get window handle of installation wizard, and that way solve this problem?
You didn't quite mention this, but I'm guessing that you are invoking your custom action off a DoAction ControlEvent, published off of something like a button click. Underneath the covers, this is very different from scheduling it in the InstallUISequence. MsiProcessMessage doesn't work from DoAction.
For proper integration with the Windows Installer UI experience, you should avoid using MessageBox.Show (your method 2). Better-integrated options include:
Tweaking a message that can be shown on the dialog from which you invoke this action
Showing a popup message by conditionally invoking a SpawnDialog ControlEvent
Showing an additional wizard panel by conditionally invoking a NewDialog ControlEvent
All three of those involve editing the UI of your project, but differently.
Related
I am using a C# custom action followed by a SpawnAndWait Dialog.
Something Like
PROPERTY WORK_DONE="False"
1.LaunchCustomAction (This does some work and sets WORK_DONE to True)
2.Show SpawnAndWait (Exit when WORK_DONE="True")
Problem,For SpawnAndWait Dialog to Appear, I need to mark my CustomAction as
asynchronous, that is to continue installation without waiting for the custom action to finish. But Whenever I do this, Properties are not getting updated and as a result SpawnAndWait Dialog doesn't get closed automatically.
If I don't mark my Condition as async, The dialog doesn't appear and it waits for the custom action to finish first.
My Requirement is to Show a small popup window that lets the user know that there is a background task going on, Please wait.
Please let me know what am I doing wrong.
I am using C# custom Action via Wix Toolset to build the custom action and AdvancedInstaller to build the installer.
I would highly recommend you (if you are willing to) to write your custom action as an unmanaged custom action written in native C++ and use the MsiSetProperty function to set your property. There are lots of Windows Installer incompatibilities and limitations in what regards its integration with managed custom actions.
If you still need to use a managed C# custom action please try to add your custom action as a custom action with sequence in Advanced Installer if this configuration is suitable for your scenario.
I am writing a wix project to deploy a website.
I am using the <iis:Certificate> element.
If the CertificatePath is not correct, or the PFXPassword is not correct, the installation failed, but the installer didn't prompt error message. I could only find the error in the log file.
Is there any way to prompt the user about the installation failure if there any error happens?
This is the way iis:Certificate element is implemented. Basically, it is a deferred custom action behind the scenes, which receives the information from another custom action and tries to do its job using the data it got.
All checks should go before the deferred part starts. I suspect that you pass the CertificatePath and PFXPassword as properties, and perhaps user enters the values. Anyway, you have to validate the values of those properties before letting it go further. If the value is not what you expect, you should prompt the user to fix it and don't let the installation flow to proceed without this.
It can be a custom action which is tied to the Next button on a wizard and doesn't let you move to the next dialog unless the properties are valid.
Using a custom managed bootstrapper application, I am unable to get the setup progress to stop when the cancel button is clicked. I pull up a confirmation view with Yes/No options. Once cancellation has been confirmed, the setup rolls back just fine. Or, if declined, it continues along. This was done in accordance with:
Cancel Installation and Rollback using wix burn Bootstrapper UI
I noticed same problem also occurs in the WiX setup kit itself, where you could click cancel and wait, and the setup instead of waiting for user to confirm or decline cancellation, continues along.
So, my question is, how do I pause the progress, until the Cancel command is confirmed (or declined) in the confirmation view?
Update: I am attempting to do this by the following mechanism:
Add a new property called CancelWaiting. If CancelWaiting is true, then in the ProgressViewModel, change the logic such that the <PropertyChangedEventArgs>.Result is set to Result.Suspend. The challenge here is to do multiple command binding. The other way would be to combine the Cancel and CancelWaiting paths into one. Anyway, I'll update this thread once I get this going. If anyone has any other ideas, please do post.
Returning Result.Suspend will instruct the Burn engine to stop the installation as soon as possible and keep the Bundle registered to execute again. That is not likely what you want to do.
If you want to prevent the progress from continuing, then you must have the progress callback method wait and not return. You can either do that by showing the message box from the progress callback method or have the progress callback wait on an event and signal the event after the user makes a choice on the UI thread.
I know this is old, but my approach may help someone else struggling. I faced the same issue where I had to pause the progress of the installation/uninstallation of custom burn wpf app.
So this is how I solved it:
I created a popup a modal window via Window.ShowDialog(), because the gui thread will block until the popup is closed.
When user press exit/cancel you can do something like this:
ModalWindow newWindow = new ModalWindow();
newWindow.ShowDialog();
You can add new Window and call it in this way. That will pause the UI thread till user close or give feedback to ModalWindow.
But if you are looking for other approach, here is a good read
http://deanchalk.com/wpf-modal-controls-via-dispatcherframe-nested-message-pumps/
I would like to show the my custom dialog rather than the message box when Launch Condition failed in Wix. Normally, the message box of Launch Condition has OK button, but I would like to make more than that with some further actions with my dialog.
Could you please advise me how I can make it?
Thanks.
Dialogs can be sequenced using the InstallExecuteSequence and Custom elements. Schedule it prior to your Welcome dialog and after the LaunchConditions action. You may want an error custom action scheduled in the execute sequence to handle logging during silent installs.
You may also want to author your dialog into the main wizard loop (after install welcome ) using Publish elements also. It's hard to say without understanding your exact needs.
I am launching a custom dialog in my uninstall sequence to gather a handful of data items from the user ultimately to run a custom action to undo an install time custom action. unfortunately none of the property values from the UI are being updated...? They are all blank when I get to my custom action code.
I have read most of the related posts on the web, and I understand not many people are doing uninstall dialogs, being that it will not show in the add/remove version of the uninstaller, and the possibility of getting around this using the ARPNOREMOVE, etc...
Considering I do want to use the uninstall dialog, why aren't the properties being updated? I added the dialog to the install time sequence and the properties are there in the custom action, so I don't believe it is a configuration problem with my dialog or properties. What is different about the UI -properties in the uninstall?
There could be a number of problems:
The properties are not public (app caps names). Only public properties are passes to the execution phase of the installation. More details here.
Your custom action runs deferred and it does't have access to the installation context. More details here on how to access context data from a deferred ca.