Using Wix, I would like to run an executable (that is being installed) and capture the return value. I have no problem running the executable via:
<CustomAction Id="UpgradeDBFromExe" FileKey="UpgradeDB.exe" ExeCommand="/update" Execute="deferred" Impersonate="no" Return="ignore"/>
But i'm not sure how to capture the return value. If I change the return to 'check' then on failure the installer rolls back (not what I want to happen), instead I want to check this result later (presumable via a property) and display a warning. My thoughts are to use a CustomAction script to call the executable and store the result as a property but this seems messy. Is there any better way to do this?
I will assume that this CustomAction makes a change to the system and therefore requires privs and is therefire scheduled as deferred / no impersonation. Because of this, and the fact that it's an EXE custom action that's running out of process, MSI doesn't provide a way to set properties. If you use the WiX Quiet Execute Custom Action pattern you could capture the stdout and log it but that's about it. If you used a DLL custom action type you could check the UILevel property and optionally popup an MSI MessageBox asking the user if they want to continue and based on that you could return success or failure but as an EXE you are kind of stuck.
Another approach would be to have another custom action run in the UI Sequence after the execute action that validates what the EXE did and set a property for success/failure and then drive some UI off of that. My only concern there is it's too late to roll the install back and users tend to not read what you put in front of them anyways.
Related
I am using WiX and want to know if we can disable a control in a built-in dialog. My requirement is to disable the "Browse" button in the "CustomizeDlg".
This became too long for a comment. I might "evolve" it as an answer if we get more information about your scenario. Just a couple of heads-ups for you.
If you are trying to prevent the setup from being installed to a non-standard path, then you should account for the fact that the installation directory can be set at the msiexec.exe command line when the setup is installed in silent mode. Sample (untested by me - first thing I found :-) ).
I suppose a custom action could be used to abort the setup if it is installed in silent mode to a non-standard path? An immediate mode custom action before InstallInitialize somewhere I guess, but after costing actions (CostInitialize, CostFinalize, FileCost, InstallValidate, etc...) - but frankly, why do this? Perhaps you could illuminate your use-case?
Oh, and please don't leave the standard action RemoveExistingProducts to run before your custom action (in the InstallExecuteSequence). This would remove the existing, related installation on the box (if any) and then abort the major upgrade operation leaving no install left on the box.
And don't add your custom action to the user interface sequence - there is no need. This sequence is entirely skipped in silent installation mode, and if there is no way to set a custom path in the GUI, it can't be changed there anyway (and the InstallExecuteSequence's custom action would catch any changes should they be set anyway - it will do).
Per this thread which discusses how to enable the button, what you need to do is the reverse: ensure your Feature elements do not specify a ConfigurableDirectory, or that it is not public by using some lowercase letters in the identifier.
I have a custom action which pops up a dialog. I would like to suppress the custom action using a condition property if my installer is being run in quiet mode (ie. /q in msiexec). How do you do that?
I know I can use a property:
msiexec /i .msi /qn SUPPRESS_MY_CUSTOM_ACTION=1
and then
use Condition property of:
NOT SUPPRESS_MY_CUSTOM_ACTION
But, it would be better to just be able to know if I'm in quiet mode.
Custom actions scheduled in the execute sequence should seldom have UI. A rare exception would be an abort, retry, fail type dialog where a retry could result in a successful installation. The custom action should check the built in UILevel property to determine if it's appropriate to display a UI.
You probably don't want to suppress the custom action completely as certain default assumptions can probably be done without a UI. Otherwise you might also want to consider factoring the custom action out into the UI sequence and Execute sequence.
Agreed with what Christopher says. But in addition to being able to condition off of UILevel (which works in either the action's condition, or inside the action's code itself), there's another approach. Change how you put up your UI from calling something like MessageBox directly to instead call MsiProcessMessage (with e.g. INSTALLMESSAGE_USER) to have Windows Installer show the message box. It will internally handle the equivalent of checking UILevel, but note this other approach will not work from a Control Event.
I am a bit of a beginner at InstallShield (in the sense that this is the first time I've used it!).
I have some code that I am packaging up in a .net DLL to check for the existence of anti-virus. The installer I am attempting to create must check for anti-virus (by calling a custom action using my DLL?) and cancel the install if none has been found.
The way I seen it working, was the user would see a dialog that is informational ("about to check for anti-virus"), the user would press "Next" it would call the custom action and then show a success screen with a "Next" button, or a failure screen with "Finish" button.
Is this sort of thing possible with InstallShield? Are there any good tutorials out there for doing this sort of thing?
Do you really need a custom action? Do you have more detailed requirements with regards to what products and versions you are looking for?
InstallShield / Windows Installer has a built in search pattern that can look for registry entries, files, et al.
If you really do need a custom action, how long do you expect the execution to take? If it's only a couple seconds, just schedule it to run after AppSearch. You don't need a UI to say "now doing blah" just do it.
Since you want to do this in .NET, you need to look at Windows Installer XML (WiX) Deployment Tools Foundation (DTF). You can use this to author/compile custom action DLL's that InstallShield can then consume. Generally the custom action should do it's search and then set a property based on it's result. Then use that property in evaluating whatever business rule you are trying to implement.
I want to close running instance of my application on repair option of my setup....
This can be done through a custom action. There is no predefined support for it, so you will need to write your own custom code. A good approach is sending WM_CLOSE to the main application window and let it close itself.
To run this custom action only during repair, you can try conditioning it with REINSTALL property.
If you want to avoid the Files In Use dialog, you will need to run this custom action before InstallValidate action. In this case you cannot use REINSTALL property, but you can use this condition:
Installed
It evaluates to true when your package is running in maintenance mode (modify, repair or remove).
I'm making an installer that uses certain custom actions. I want to create a rollback action that undoes this changes when the installation is cancelled or unsuccessful.
What I've tried so far is what the documentation tells you to do, which is call the CA in deferred-mode and set "rollback only" in the In-Script Options. if you cancel the installation, the moment the installer tries to call the CA, the installation fails, it doesn't matter what the content of the CA is, it always fails the moment the installer tries to call it.
It says the installer couldn't execute a find a program necessary for the installation (the CA), even though the CA is called with "Run WiseScript From Installation", so the CA SHOULD be there.
It sounds like the setup is hitting an error inside your rollback custom action. The first thing I would do to prevent the setup from bombing out would be to mark the rollback custom action with "don't check exit code".
I haven't used Wise in a while and don't know exactly where you find this in the GUI, but it shouldn't be that difficult. It is probably a flag you can set when you insert the custom action into the InstallExecuteSequence.
Secondly you would need to start debugging the actual content inside the custom action to determine where it crashes and obviously resolve the root of the problem before the rollback action will work properly. Sometimes it is sufficient to just use numbered message boxes to track the progress of the code in the custom action at runtime, but at other times you need to use the debugger feature to step through each line in the custom action code.