I have a custom action which must be executed if the spesial feature's action state is "install". Now I am using next condition:
(&ca_feature=3 AND NOT &ca_feature=2) OR (!ca_feature=3 AND PATCH) .
I want to execute it also in Modify Mode. When the feature is already installed and user do not want to delete it. I thaught to append OR (REINSTALL><ca_feature OR REINSTALL=ALL) to my condition string. but it seems not working.. I can't get how the MSI is working in some situations, that is my problem. but i also can't find the answer in the internet.
Please,tell me what i'am doing/understanding wrong?thanx in advance
The condition looks correctly. The last part with REINSTALL would be true if your feature is to be reinstalled.
Although you can try to use !ca_feature=3 instead of REINSTALL><ca_feature: that would run the CA when the feature is installed.
I think your condition could look this way:
(&ca_feature=3) OR (!ca_feature=3 AND NOT (REMOVE><ca_feature OR REMOVE=ALL))
It would run the CA when this feature is scheduled for install, or if it's installed and is not scheduled for remove.
This part AND NOT &ca_feature=2 in the first parenthesis is redundant because &ca_feature cannot be equal to 2 if it's already equals 3.
Use MSI verbose logging to better understand what's going on. Run your installation this way:
msiexec /i package.msi /l*vx log.txt
When a feature state changes or a property is modified, you'll see a message in the log. Then you'll be able to compare the actual values with your expectations. Use other operation switches instead of /i to run it in modify or remove mode.
Related
I have two features in my installer. I need to show a special dialog only for Feature1
I used this condition <![CDATA[&Feature1=3]]> so it works for first time installation. Now if i run this installer for second time, i need to check whether Feature1 has Checked on or not. (even if it already installed)
I tried Installed AND <![CDATA[&Feature1=3]]> this works when first time Feature1 has not installed.
Lets say if i run this installer as follows. I need to true the condition (Show the dialog) for both time.
First installation:
Second time installation (for change)
Can anyone help me to put a condition for that?
You're using, and looking for further Feature and Component State Values, but I'm unclear exactly what behavior you desire. Examples of Conditional Statement Syntax includes the following example:
Run action only if the product will be installed local. Do not run action on a reinstallation.
(&FeatureName=3) AND NOT(!FeatureName=3)
The term "&FeatureName=3" means the action is to install the feature local. The term "NOT(!FeatureName=3)" means the feature is not installed local.
It sounds like you may wish to tweak this by removing the NOT, and changing the AND to OR. If you do so, the result would be a condition that is true whenever the feature is already installed or is about to be installed.
Alternately, you may wish to exclude the scenario when the feature is about to be removed. If so, you could craft it similarly to this:
(&Feature1=3 OR !Feature1=3) AND NOT(&Feature1=2)
This is true if the feature is about to be or is already installed, unless the feature is about to be removed.
As a side point, I would suggest either putting the <![CDATA[ ... ]]> around your entire condition, or excluding it entirely. I find your example of Installed AND <![CDATA[&Feature1=3]]> to be harder to read than either the fully-wrapped<![CDATA[Installed AND &Feature1=3]]> or the entity-escaped Installed AND &Feature1=3.
I'm new to wix and have a very important question
My installer should ignore the return status- meaning it should complete successfully but I do need to display to the user a warning with the return status in case it did not succeed.
or even better check the code and analyze accordingly
how do I do it with wix installer?
WiX generates MSI files, and when they run you don't have any control over what the return value will be. You also may be unaware that it's a transactional install. If it works it works and everything is fine, if it fails then it will rollback and restore the system to its starting point. This behavior can be screwed up to a certain extent if you add your own code (in a custom action) to change the system and then don't write rollback code to undo what you did, but there is no partial install that you need to warn anyone about.
In your Wix project file, you could insert the Warning task
at the appropriate place.
I want to add customized dialog box for uninstallation of my application.
I have also tried the following:
<InstallUISequence>
<Show Dialog="RemoveDlg" OnExit="success">REMOVE="ALL"</Show>
</InstallUISequence>
Is it possible or not in wix? Can anyone help me out with this?
While you can certainly author dialogs that are specific to product removal, uninstallations started from the remove button in Add or Remove Programs (now Programs and Features) are run without the UI sequence, and thus will not show these dialogs. One common alternative is to set the ARPNOREMOVE property which then requires the end user to click Modify instead of Remove. The modify button starts maintenance, which does show your UI.
Unless the data in %appdata%\product\ can cause problems for a re-installation of the application I would recommend leaving it in place on uninstall. Whatever you install in this folder is considered user data, and should not be automatically removed by default - and often not as an option either. Many companies apply custom permissioning on the userprofile folders. Messing around in there could cause your MSI to hickup seriously - particularly on terminal servers by triggering self-repair (which is generally not allowed on TS).
Keep in mind that the same installation sequence is used for install, uninstall and patching. If you use major upgrade patches that essentially uninstall and reinstall the product you could end up deleting the user data and reinstalling it for every installation. If this is acceptable, the data you deal with is not user data, and is hence located in the wrong place on disk.
If you run a delete operation towards the end of the uninstall via a custom action that checks exit code, you could trigger rollback of the uninstall, essentially causing the product to be reinstalled and be impossible to uninstall! Rare, but it happens. If the custom action is run after InstallFinalize and hence outside the MSI install sequence your setup could return an uninstall error code and leave your product broken and the uninstall incomplete or your product partially unregistered.
In short I wouldn't mess around with this. If you have insistent customers I wouldn't mess with a dialog if I could help it. I would add a PUBLIC property to control whether a custom action is run immediately prior to InstallFinalize. Flush any error return codes and write information into the MSI log instead. Then users could uninstall user data by specifying the property on the command line or hard code it in the Property table.
If you have to have a GUI you can use the same property to set from a custom dialog to control whether deletion is done or not. Remember to condition the display of the dialog with care. I.E don't show it during patching operations.
The installer I'm writing using WiX 3.0 uses a RegistryValue element to modify an existing registry value (originally written by our main product). I'm trying to figure out a way to restore the registry value when the user uninstalls my utility. I'd like to avoid using a custom action, but that might be the only recourse? TIA.
I did this. The registry value in question was the application associated to a file extension, but it could be any registry value.
My first idea was to use a "custom action" for install and uninstall to preserve
and restore, respectively, the associated regy state. This
seemed simple enough.
I created a setup project in VS2008 and built the CA's as javascript files. The "on install" script grabbed the existing regy value and stashed it into a well-known place. The "on uninstall" script would look in the well-known place, and then put the value found there, back in the original location.
Easy, right?
There were two problems:
the script that ran during install, to preserve the pre-existing registry value,
runs AFTER the registry has already been updated
with the values for the newly installed thing. So it preserved the new setting instead of the setting that was there before the MSI ran. Not useful.
The script that runs during uninstall, runs AFTER the registry values, and in fact the entire directory subtree,
have been deleted. Including the stashed value. So it had lost its state.
To solve that I wrote another script that
re-orders the custom actions so they run at the proper times.
There's actually one more twist. Obviously, the "Restore" script (on
uninstall) won't work if it is run after the registry entries for the app have been deleted. I can't remember now, why... but I also determined that this script could not run before that. Somehow that wasn't working either.
So, I modified the MSI to run the restore script
twice. In phase 1, it transfers the stashed value to a "parking lot" in the registry.
Then the application's Keys and Values in the registry get deleted, but the parking lot remains. In
phase 2, outside the transactional protection, the restore script retrieves the state from the parking lot, restores
the file association, and then deletes the parking lot.
I can't remember exactly why I needed to do this in 2 steps, but I remember fighting with it for a while before coming up with that solution.
The way it works in development:
set the on install and on uninstall CA's in the VS project
build the VS Setup project
run the post-processing script that modifies the MSI.
When using the MSI, it's a little more complicated than I originally thought but it works.
If you are using WiX, you may have more control over the time and ordering of the steps, so may not need that post-processing step.
Finally, you said you wanted to avoid a CA. To me, CA's are avoided because they are painful to produce in C++, and producing them in .NET is often inappropriate. But, it's pretty simple to use Javascript for CA's. Some people think script is the wrong tool for the CA job. I think that's wrongheaded. I think script is a very good tool for this purpose. And once you can accept script as a good tool, then you don't need to hold your nose about creating a custom CA.
The registry table is incapable of writing a registry value during an uninstall so it is correct that this must be done via custom action. I am of the opinion that using script is bad. Whether you choose to listen is up to you. I can tell you that just the other day I was called into to trouble shoot a situation where some wrote a vbscript CA that was failing because the file system object had been unregistered as part of a security lockdown process.
I suggest C++ or C#/DTF depending on your needs.
Faced with similar issue, need to update the registry value on install and restore to previous value on uninstall.
Is the only solution possible is creating a custom action for this purpose?
I found a extension for wix that has fucntions for this purpose
link to wix extensions
I want to add customized dialog box for uninstallation of my application.
I have also tried the following:
<InstallUISequence>
<Show Dialog="RemoveDlg" OnExit="success">REMOVE="ALL"</Show>
</InstallUISequence>
Is it possible or not in wix? Can anyone help me out with this?
While you can certainly author dialogs that are specific to product removal, uninstallations started from the remove button in Add or Remove Programs (now Programs and Features) are run without the UI sequence, and thus will not show these dialogs. One common alternative is to set the ARPNOREMOVE property which then requires the end user to click Modify instead of Remove. The modify button starts maintenance, which does show your UI.
Unless the data in %appdata%\product\ can cause problems for a re-installation of the application I would recommend leaving it in place on uninstall. Whatever you install in this folder is considered user data, and should not be automatically removed by default - and often not as an option either. Many companies apply custom permissioning on the userprofile folders. Messing around in there could cause your MSI to hickup seriously - particularly on terminal servers by triggering self-repair (which is generally not allowed on TS).
Keep in mind that the same installation sequence is used for install, uninstall and patching. If you use major upgrade patches that essentially uninstall and reinstall the product you could end up deleting the user data and reinstalling it for every installation. If this is acceptable, the data you deal with is not user data, and is hence located in the wrong place on disk.
If you run a delete operation towards the end of the uninstall via a custom action that checks exit code, you could trigger rollback of the uninstall, essentially causing the product to be reinstalled and be impossible to uninstall! Rare, but it happens. If the custom action is run after InstallFinalize and hence outside the MSI install sequence your setup could return an uninstall error code and leave your product broken and the uninstall incomplete or your product partially unregistered.
In short I wouldn't mess around with this. If you have insistent customers I wouldn't mess with a dialog if I could help it. I would add a PUBLIC property to control whether a custom action is run immediately prior to InstallFinalize. Flush any error return codes and write information into the MSI log instead. Then users could uninstall user data by specifying the property on the command line or hard code it in the Property table.
If you have to have a GUI you can use the same property to set from a custom dialog to control whether deletion is done or not. Remember to condition the display of the dialog with care. I.E don't show it during patching operations.