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.
Related
While I was searching for the answers I found that the registry entries are made during installation only. In my installer once the installation is done then there comes a dialogue box which contains one checkbox. Based upon the checkbox value I want to make the registry entry.
Please suggest.
All system modifications (such as file installation or registry modifications) should occur DURING installation. There is a REASON for that - to make installation transactional (all or nothing), and to allow clean uninstall and repair.
Suggestion: if you want to put some user setting (a-la 'user agreed to receive marketing emails'), better do it yourself (as a custom action for example). Or better yet, in your own program (do not put it in the MSI installer)
A custom action in principle can be run in any execution sequence (including UI sequence), so you will be able to run it any time (i.e. even after that dialog)
Another option is to collect data (checkbox value) BEFORE install. Then you can include it as part of normal install sequence (as registry element)
I have a wix installer with five features. My current version is 0.0.0.125. I am installing this in one machine with first three features. Later i wish to install the remaining two features and so deselected first three and selected the remaining two features.
So this time the first three already installed should not be deleted, and the remaining two features should be installed. But when i install the same build second time, the three features are automatically removed from the destination location and the selected two features only installed.
I used RemoveFile child attribute to each Component to overwrite and when i manually copied the file and pasted into the destination directory, next time when i install the same version installer, it is not overwriting and deselected(previously installed features) features also deleted. So i have restricted this by adding 1 in InstallExecuteSequence.
i)I need to overwrite all the files
ii) Each installation of the same installer should not delete the previously installed files
Thanks
I can't tell exactly what you mean by features and installing the same setup twice, but:
You cannot install the same MSI setup twice. It's already installed (the ProductCode) so it will go into maintenance/repair mode. This may do a repair/reinstall or, if you've authored it for feature maintenance, then Windows will again notice that the product is already installed but offer the standard feature dialog which lets you add features from the setup, and this latter mode is exactly what you get if you go to Programs&Features and choose change. In other words a true feature maintenance setup offers the feature selection dialog primarily from Programs&Features, and in your scenario with adding two features you'd simply use Change from Programs&Features and not attempt to reinstall the same setup.
Your post refers to Components and RemoveFile, and you should definitely not need to do any of this. If you're not using true Windows Installer features and have built a Component-based setup where Component installation is based on conditions then that would explain what you are seeing. The property values used for your conditions are not preserved so when you attempt to install the same setup again it goes into maintenance reinstall mode for the currently installed product, the property values are empty, the conditions are false, so those components are removed.
Having said all that, you haven't posted your WiX, and the fact that you're attempting to install the same setup twice implies you may not be familiar with maintenance, features and components. In summary, it seems that you should be using the WixUI_FeatureTree dialog set, grouping your components into features to achieve what you're looking for.
If your aim is to replace files that need updating then you should look at the WiX MajorUpgrade element. If you set MigrateFeatures to yes then the upgrade will result in the same features still be installed after the upgrade. Schedule afterInstallExecute is probably what you want. Increment file versions of files you want updating, use a new ProductCode, increment the ProductVersion in the first three fields and use the same UpgradeCode. Alternatively you could look at creating a patch, an msp file.
Usually you would set Permanent="yes" for files that you want to keep on a computer after un-installation and "no" if want to remove or overwrite them.
For example:
<util:XmlFile Id="fileId"
Action="setValue"
Permanent="yes"
File='[INSTALLFOLDER]pathtofile\yourApp.exe'
ElementPath=""
Value=""
Sequence="1"/>
Hope this helps!
I am writing my first WIX installer. The installed application uses various Microsoft standard OCX controls which are installed as merge modules, for example MSCOMCTL.msm, MSFLXGRD.MSM etc.
For some reason, if the target machine has UAC switched on, running the application after installation fails with a message to the effect that "MSCOMCTL is missing or has not been correctly registered...". However, if the application is run once 'As Administrator' it puts up a UAC "can this app make changes" message (so it's obviously changing something) and then runs fine, and what is more runs forever after without admin privs. (Alternatively, registering the relevant controls with RegSrv works as well).
I have monitored the application with ProcMon and it is obviously doing a late registration. It is as if the installer has advertised the contents of the merge module without installing them. I've also looked at the merge module, and my MSI, with Orca, but I can't work out any way of stopping this behavior.
I did wonder if it was anything to do with the versions of the MSMs, but it seems almost impossible to find out what the latest version of these Microsoft MSMs is, or to find anywhere to download them.
Obviously we do not want to make our customers go through this convoluted process when they install our product. Any suggestions would be greatly appreciated.
Thanks Kiran. We also read that bit in the MSDN documentation. The problem is that we can't alter the Advertise attributes on items that are already built into Microsoft's Merge Modules (well, we could using Orca but it would be messy).
However, I think we may have found the source of the problem. The previous release of our product used a kit built using InstallShield. When we compared the .MSI created by InstallShield to the one created with Wix we noticed that the InstallExecuteSequence table of the IS one contains RegisterProgIdInfo, RegisterClassInfo and RegisterTypeLibraries, which do not appear in the Wix-generated MSI. We think some or all of these may be needed to force the MSMs to install. I need to find out how to put these into Wix, and then to try it to see if it works. I will try to remember to post the result here for posterity.
[Following day] Confirmed. For anyone else who has this problem, you just need to put a <RegisterClassInfo/> tag and a <RegisterProgIdInfo/> tag (and maybe a <RegisterClassLibraries/> tag, but I didn't need one of those) into your <InstallExecuteSequence>.
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.
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