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!
Related
I have an MSI, which adds a registry key, installs and starts some services, installs a file and so on. Now, there is a requirement to update one file and add a new file. I know we can create a Patch by creating a difference / transform. But in my second MSI, I only want to include these 2 files (the updated one and the new one) and not the other files, probably like a HotFix. I don't want to create a Patch. I did try to create a separate MSI but with the same UpgradeCode but with a different Product ID and a different version. But this creates a new entry in Programs and Features. Also, while uninstalling this new MSI, it does rollback the new file, but it doesn't rollback the modified file (this file was originally created by the first MSI and modified by the second one). At least if it is able to rollback and restore the state during uninstallation, it would have been great. But it is not rolling back the modified file properly.Has anyone come across this scenario? If so, have you been able to find a solution without a Patch? Please help.
There are three ways to update an installed product: a patch, a major upgrade and a minor upgrade. Although you can create a new MSI that replaces some of the files in an existing product what you are actually doing is sharing them in the same way that Microsoft Dlls (for example) are shared between many different products. (Unless you use the same component Ids and share properly you are more likely to break the product instead of updating it.) This is why you see that behavior of preserving files.
The idea that the patch may contain "contain other changes also which he is not interested in" should not be an issue. You create the patch so that it contains only those changes. It will contain other changes only if you put them in the MSI file when you create the patch.
Adding files during a patch can be tricky because there are some rules involved.
The safest thing to do is a major upgrade when adding new files.
So the choces are:
A patch that contains only the required updates.
A major upgrade, which is the complete new MSI file that upgrades the product.
A minor update which again is the complete new MSI file with the same ProductCode, incremented version, only minor hotfix changes, install with a special command line that includes REINSTALL=ALL REINSTALLMODE=vomus
Only the patch can be made to include just the changes required.
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>.
How can I achieve the following: Before product A is installed, uninstall product B, but only if it is installed in the same installation directory.
Product A and product B are completely independent and different products, i.e they have different product codes and upgrade codes.
I assume that "same installation directory" means the browsable folder that a user can choose, and therefore you don't know if B is to be uninstalled until the user chooses the folder and the installation is committed to start (because of Back buttons). Obviously if there are file or registry conflicts in other locations there is a bigger problem.
Perhaps the easiest way to do this is:
Use a ComponentSearch for a component id in A's installation directory, that will give you the path to that component.
Compare that path with your installation folder (after it's chosen) to see if they are the same - I know of nothing built-in to do that. So use a custom action and set a property if they are the same.
It doesn't matter that the UpgradeCodes are different - you can have an Upgrade element that refers to A's UpgradeCode and do the upgrade automatically, perhaps the odd part being that you condition RemoveExistingProducts on the path compare property true and the upgrade property set, the one that you define in the UpgradeVersion element. That will clearly affect your ability to upgrade your own product, and you haven't said if that's a requirement or not. If it is an issue, then you'd add your own UpgradeCode in an Upgrade element with another UpgradeVersion property for detecting that, then your condition on REP is the condition for removing B OR your own upgrade property, and both will be uninstalled and your A installed.
I know that you can upgrade the versions, remove the old the installation and install the new version.
and I know you can also support two installations of the same software on the same machine.
Is there a way to create a GUI installation which let's the user choose if he wants to upgrade or keep the old version and install the new instance in addition to old the ones?
Yes, but it's not simple.
Basically you start with two upgrade table entries. One that is fake and would never detect a product and one that detects your previous versions but has the DetectOnly attribute set.
Next you need to create a custom dialog with a radio button ( install new, upgrade existing ) and a list box to contain the entries of previously detected products. You will use a custom action to populate the ListBox table with temporary rows to reflect the previous qualifying products to be upgraded.
If the user selects Install new, you just carry on. If they select upgrade existing you parse out the product codes from the Detect Only upgrade action property and put them into the "fake" action property. Now remove existing products will have something to remove.
They are all kinds of business rules you'll want to come up with and enforce, cover the silent installation story and also have a way of mutating the INSTALLDIR so the products can be side by side.
That's the basic pattern but you'll have to come up with all the details around it. I've done this several times with very favorable results.
So, I shipped this product which had a component like
<Component Id="Rates2012" Guid="{some-guid}">
<File Id="Rates2012" Name="2012-rates.dbf" KeyPath="yes"/>
</Component>
An update is going out, and we have a 2013 version of that file. This is a different component, with a different filename and guid. It supersedes the 2012 version.
All I want is for that 2012 file to be left alone (not deleted) on upgrade. But I don't want to include it in the installer just for the sake of marking it as NeverOverwrite.
That is, I don't mind including metadata about the 2012 component for this purpose, but I don't want to include the actual file, since it's large and obsolete.
Probably I should have marked it as NeverOverwrite the first time around, but I didn't. And the file should be removed on uninstall.
Not sure it will work, but this is something you can try.
have a custom action that copies the existing file to a temp location. Then include a dummy small file in your upgrade install. And post install another custom action to copy from temp location to the original location.
a hacky one but should work given the need you have.
Unfortunately, this isn't really supported by the Windows Installer. If you include the metadata about the File then you'll want to make the actual bits available in the case that your MSI is repaired and needs to actually put the file back.
This is one of those scenarios where you want to make sure you test your upgrade scenarios before shipping the product.