I am in the following situation where I need to remove a component which is marked as permanent.
A previous version of our setup installs a windows service which should be left on the system after the main product was uninstalled.
Now we try to remove the left service and replace it with an updated version. The problem is we have two different component guids out there, because of changing the tools we used to create the msi's.
In my opinion there are three possible ways to achieve the goal:
a) Use a file search to update the files itself.
b) Use a component search and try to find it. If it was not found try to find the other one. If any one found use the upgrade element to upgrade the component.
c) ??? - probably the "best practice" way
Some of my fellows mentioned to only delete the files but this would cause more trouble because of the not unregistered component in the Windows Installer registry.
I don't mentioned CustomActions here because it should be the last option the achieve the goal.
Your best option here is to open your old MSI using InstEd It! or Orca and then copy the Component GUIDs and use them in your new installer.
This way WindowsInstaller will handle the upgrade for you. Obviously this will very painful if you have hundreds of Components that are set as permanent (you only need to bother about the permanent ones), but if it's a just the service element it should be a fairly easy task.
Also make sure your UpgradeCode is transferred across and do a MajorUpgrade so that your old installer is un-installed first.
Related
What is the standard way to handle web.config files during major upgrade.I'm aware how the unversioned files are handled during upgrade,the file will not be replaced if the file has been modified by the user.
Is there a way to deal with the scenario where in there are new entries added to config file bundled with the latest installer that needs to be installed,and also retain the existing entries modified by the user during major upgrade in Wix.
The simple solution that a lot of my customers have liked is to not put user data in the web.config. Instead we use the AppSettings#file and ConnectionStrings#ConfigSource elements to specify an override file and keep the user data there. What MSI doesn't know about it won't tamper with. Now you don't have to be an MSI component rules wizard.
https://msdn.microsoft.com/en-us/library/ms228154(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/system.configuration.sectioninformation.configsource(v=vs.100).aspx
I know the question is for Wix, but just wanted to point out how much time commercial tools can save in such scenarios.
For example, using Advanced Installer you can read and load into an MSI property any XML values and then use the XML Files updater to write dynamic content in the files, at install(upgrade) time. (check the videos at the end of each article for a quicker overview)
Disclaimer: I work on the team building Advanced Installer.
Set the component to always overwrite and write a custom action to add the needed information to the config file.
The only way that seems possible is a custom action to merge the entries in the new file into the existing file, because you want data from the existing a new files. You would also need the upgrade scheduled late (after InstallExecute) so that the upgrade isn't an uninstall of the old product followed by an install of the new product.
If you are doing an upgrade (the WIX_UPGRADE_DETECTED property will be set by a MajorUpgrade element), so update the existing file, otherwise install the new one.
There might be a way to express the updates as an Xml transform, so something in the WiX util:xml tools might help do an update.
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 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.
I need some advice about how to clean up an old Wix project that hasn't been managed very well. One problem is that the project currently has multiple entries for the same files, going to the same location. For example, several .wxs files in the project will define a new component for foo.exe, each using a different GUID and each sending this file to the same DirectoryRef. This hasn't yet created any issues, but now I want to use patches (MSPs) in our product and this sort of thing messes with their operation.
I'm wondering about the best way to resolve this without breaking upgrades (since all previous installers have gone out like this). If I simply remove all the duplicate components, we get undefined behavior during an upgrade. I think what's happening is that removing one or more duplicate entries will cause the installer to generate delete operations for that file. Even if the remaining entry for the file is a new version, there is no guarantee in the order of operations during the install. So some of these files will first get updated, then one or more delete operations will remove the updated file. Thus at the end of the upgrade several files will be missing. Running a repair immediately afterwards will restore the files, since the installer knows they are supposed to be there.
I imagine one way to resolve this is to do a one off "hack" in our next release, where we copy these files into a secondary location, then run a custom action post install that copies the files from the secondary location into the primary and delete the temporary directory.
Is there a cleaner way this could be resolved?
What you are likely going to have to do is use validation to identify all the duplicates and fix them. Then change your upgrade to be a major upgrade with the earliest possible scheduling. You may also have to change your install location to a slightly different directory to get around component reference counts breaking.
Once clean you should be able to go back to minor upgrades and start thinking about patching. An alternative would be "fake" patches. I've used an MSI that doesn't publish itself as a hotfix method very successfully. It breaks a lot of rules but can be useful for organizations that don't care about patching rules and just want to make the business happy.
I am trying to write a Wix3 install for a visual studio add-in.
I have it just about there, but I need reset the plugin by deleting a registry entry. Specifically any value starting with
HKCU\Software\Microsoft\VisualStudio\8.0\PreloadAddinStateManaged\MyAddinName.Connect;
How to a convince Wix to delete any such entries?
You need to use registry element.
http://wix.sourceforge.net/manual-wix2/wix_xsd_registry.htm
This should solve your issue you're having. There is a great WiX tutorial and registry is discussed in chapter called Beyond Files.
Is your issue the need to do a partial match on the registry value. If not, then you might be looking for the RemoveRegistryValue element (nests under Component). If yes, then I would think you'd probably need to create a custom action to search for the registry value(s) to delete and populate the RemoveRegistry table with what you find. I would think a DTF (Deployment Tools Foundation) custom action would a viable option.