I am building an installer with Wix 3.10 that will install files, create a service as well as create and populate a database.
I am using the Wix sql:SqlDatabase element to create the database and run some sql scripts to populate it during installation (based heavily on WIX database deployment, installation)
As recommended in the Wix documentation, I am testing a mock upgrade before releasing the initial installer. From what I can tell sticking to major upgrades is strongly recommended and so I am using the MajorUpgrade element as per the examples.
Unfortunately however during the major upgrade I can't seem to prevent Wix from uninstalling the database, nor can I find any guidance on how to handle this. I understand that a major upgrade is effectively an uninstall of the current version followed by a fresh install of the new version, but surely there is a way of retaining parts of the original?
I have a similar problem with the service that I install too, but based on this SO question Wix Major Upgrade: how do I prevent Windows service reinstallation? the solution appears to be to add a condition to the delete service entry of the install sequence:
<InstallExecuteSequence>
<DeleteServices>NOT UPGRADINGPRODUCTCODE</DeleteServices>
</InstallExecuteSequence>
This implies to me that it is possible to retain entries across a major upgrade, but I may be misunderstanding.
Unfortunately there does not appear to be any equivalent installexecute sequence element for a SqlDatabase entity. Is there any guidance on how one should approach this?
UPDATE
Based on PhilDW's answer, changing the sequence or schedule of the major upgrade is done by changing the Schedule attribue:
<MajorUpgrade
DowngradeErrorMessage="A newer version of [ProductName] is already installed."
Schedule="afterInstallExecute"/>
Note however that this will only take you so far - if you plan to add support for trusted authentication as well as SQL authentication in your installer (as per the SO article above) it will not work, my assumption is that Wix determines that one component was never installed (whichever authentication option was not chosen) and therefore will always drop the database.
There are a few ways to address this, depending on the internals of your MSI:
A major upgrade that is sequenced at the "end", after InstallExecute and just before InstallFinalize, means that the upgrade is basically an install of the new product on top of the currently installed product. File overwrite rules apply, one of which is that data files won't be replaced if they have been updated after installation. So data files are saved. Other considerations are that binary file versions must be updated for those you need updating, and component rules must be followed.
If the issue is based on custom actions that run when the older product is being uninstalled, then you can use a custom action condition such as REMOVE="ALL" and not UPGRADINGPRODUCTCODE. UPGRADINGPRODUCTCODE is set in the older product as it is being uninstalled, not in the incoming upgrade.
I believe some WiX util types custom actions are based on the uninstall of the related component, so you wouldn't need that condition in 2. A major upgrade after InstallExecute increments the ref counts of each component (which is why you need to follow component rules) while following file overwrite rules. So your data file would have its ref count counted up to 2, would not be overwritten, then the older product uninstall would count it down to 1, so that the component remains, and an uninstall custom action based on component removal would not run.
If there is something you need to do in the upgrading install that's custom action based, then WIX_UPGRADE_DETECTED will tell you that you are upgrading an installed product.
On the upgrade link you refer to, Chris Painter's answer is the correct one. It's basically the same point that I'm making here, so of course he's correct :)
Related
I wrote a custom action to help during upgrade of my product (from 1.0 to 1.1). Now I need to upgrade from 1.1 to 1.2 but the existing uninstaller is failing during upgrade. I got the execution conditions of my custom action wrong. (Lesson learned, always test upgrading to the next version before deploying).
Right now it seems my best option is to modify the InstallExecuteSequence table in the existing .msi to disable the failing custom actions. I'll have to create another custom action to browse the registry, locate the existing .msi in C:\
Windows\Installer, patch it, and then continue with the upgrade. This sounds like a terrible, error prone solution, but I'm really at a loss. This was supposed to be an automatic, silent upgrade pushed down from a remote cloud.
Another option would be to write a batch script to uninstall the existing product, then execute the new installer.
Any advice?
EDIT This question is already answered here: I screwed up, how can I uninstall my program?
The supported way to do this is a patch (by which I mean an MSP file, not coding to alter the cached MSI file). That's by far the most straightforward way to get out of the situation. After that, do the upgrade. Using WiX you could probably put the MSP and the upgrade in a bundle.
In any case, you wouldn't do your proposed change with another MSI. A small executable can do what you propose, and:
MsiGetProductInfo (ProductCode, …, INSTALLPROPERTY_LOCALPACKAGE)
is how you find the cached MSI.
Conditioning: What condition did you set on the failing custom action? And more importantly, what is the new condition you are intending to use? It sounds like regular uninstall works but major upgrade fails? The typical problem is that uninstall fails altogether, and then the usual solution is a minor upgrade which I will quickly describe.
Minor Upgrade: Normally what I use is a minor upgrade to fix whatever is wrong in the current install's (un)installation sequence(s). A minor upgrade does not uninstall the existing installation, it upgrades it "in-place", and the uninstall sequence is hence never called and thusly you avoid all its errors from manifesting themselves. There is no need to browse to the cached MSI file and hack it manually if you do things correctly in your minor upgrade. The updating of the cached MSI will happen auto-magically by the Windows Installer Engine provided you install with the correct minor upgrade command line.
Future Upgrades: A minor upgrade will generally always work if you make it simple enough, but the problem is usually applying it since it often targets only a single, previous version. When you get to the next release and if you then use a major upgrade, you will see the error in your original MSI manifest itself on uninstall if you are upgrading an installation that never had the minor upgrade applied - in other words it is still the oldest version of your installation. This is generally solved by a setup.exe launcher which will install the minor upgrade if need be. The bad news is that you need to keep that update in every future release - if you want to avoid any upgrade errors. Or in a corporate environment you would use the distribution system to check what is already on the box and install accordingly. If your manual uninstall works correctly (but major upgrade uninstall fails), all you should need to do is to push an uninstall command line to msiexec.exe as the first command to run via your setup.exe I think. Then there is no need to include any minor upgrade binaries in your setup.exe launcher.
Detect & Abort?: Michael Urman's answer here explains how it might be difficult to make sure that the minor upgrade is present on the box before applying the next version of your software:
InstallShield fails because of a bad uninstall. He suggests making your package better at detecting whether a new upgrade can be safely applied.
Some Links:
how to omit a component when we try to build .msi using wix (on how patching is just a distribution mechanism for MSI upgrades that must already be working)
Is there any possible way to perform upgrade when Product codes for old and new versions are same? (on minor upgrades and their technical limitations)
Here is a hack that I got working, but based on the answers above it looks like it's not the preferred way.
[CustomAction]
public static ActionResult Patch11Installer(Session session)
{
string localPackage = NativeMethods.GetMsiInstallSource("{MY-PRODUCT-CODE}");
if (String.IsNullOrEmpty(localPackage))
{
session.Log("Failed to locate the local package");
return ActionResult.Failure;
}
session.Log($"Found local package at {localPackage}");
using (Database database = new Database(localPackage, DatabaseOpenMode.Direct))
{
foreach (string action in new string[] { LIST OF CUSTOM ACTION NAMES })
{
session.Log($"Modifying condition for action {action}");
database.Execute($"UPDATE InstallExecuteSequence SET Condition='WIX_UPGRADE_DETECTED' WHERE Action='{action}'");
}
database.Commit();
}
return ActionResult.Success;
}
The custom action calls MsiGetProductInfo to query for the v1.1 MSI using the v1.1 product code which I obtained from installer log files. It then opens the MSI database and modifies the Condition property of the InstallExecuteSequence table for the list of custom actions that are failing. It changes the Condition from "UPGRADINGPRODUCTCODE OR WIX_UPGRADE_DETECTED" to "WIX_UPGRADE_DETECTED". UPGRADINGPRODUCTCODE is the property that's causing the uninstall to fail during a major upgrade as this property is passed to the uninstaller and contains the new product code; the product code for v1.2 in my case. Here is the custom action definition in my installer file.
<CustomAction Id="Patch11Installer" Return="check" Impersonate="yes" Execute="immediate" BinaryKey="MyUpgradeCustomActions" DllEntry="Patch11Installer" />
I'll look into implementing a minor upgrade as suggested in other answers. I just thought I would leave this solution here.
I am trying to delete a file using a custom action scheduled between InstallInitialise and InstallFinalize standard action.
MajorUpgrade element is used to design upgrades.
However, I want the custom action to run only during uninstall and not during the Major upgrade(this includes uninstall and install).
I have used the following conditions to execute the CUstom action:
(NOT UPGRADINGPRODUCTCODE) AND (REMOVE="ALL")
REMOVE AND NOT WIX_UPGRADE_DETECTED
Is there a way to uniquely detect the Major Upgrade using properties in Wix?
Phil has already answered. I'll just post what I wrote a few hours ago
before heading out. The conditions you specify look pretty good to me.
Maybe I'll do a quick review of things that are likely to cause
confusion - such as what custom actions run when?
Major Upgrades: A major upgrade is really an install of a new application version combined with the uninstall of the old version - with different uninstall scheduling possible (uninstall old and install new, or install new and uninstall old). Hence, during a major upgrade operation, 1) the uninstall sequence runs only for the old setup, and 2) the new setup runs only its install sequence. This is of crucial importance to understand what custom actions runs when and why.
Custom Actions and Major Upgrades: To put it in other words: this sequencing can cause quite a bit of confusion for custom action sequencing, since it could appear that an action runs from the new setup, when it in fact runs in the old setup's uninstall sequence. If you are sloppy with sequencing, the typical error is seeing the same action run many times during the upgrade process - potentially twice from each setup (four times in total - or perhaps even more - I haven't tested that in detail) - if you run the custom action in immediate mode.
No Retrofitting for Major Upgrades: As Phil explains, you can not add a custom action that will run during the old setup's uninstall sequence inside the new setup. That custom action would have had to be part of the original setup, or added via a minor upgrade (which upgrades the existing installation in-place, rather than uninstall and reinstall it).
Important:
UPGRADINGPRODUCTCODE is set only in a setup that is being uninstalled as part of a major upgrade. It is not set in the new
version being installed.
The condition UPGRADINGPRODUCTCODE is hence not true in the installing setup, only in the uninstalling setup.
WIX_UPGRADE_DETECTED is set only in setups that are using WiX's MajorUpgrade element that have detected that another version is
being uninstalled as part of its install.
The condition WIX_UPGRADE_DETECTED is hence true in the installing setup, but not in the uninstalling setup.
WIX_UPGRADE_DETECTED: To go into even more detail, WIX_UPGRADE_DETECTED is strictly speaking not a custom WiX feature - it is a WiX standard or convention for setting the built-in MSI property ActionProperty for the upgrade process. All MSI files supporting major upgrades have such a property, WiX just names it in a standard way. The property is set in a column in the Upgrade table, and it is a property that is set when a setup finds related products - that are lower versions (and hence to be uninstalled) - on the same box during installation.
WIX_DOWNGRADE_DETECTED: Note that in a standard WiX-compiled MSI using the MajorUpgrade element there is also WIX_DOWNGRADE_DETECTED - the property used to list products found that are of higher version than the running setup. These would block the setup in question from installing - in most cases (unless the settings are customized by the setup designer).
The action property specified in the upgrade table can be "anything", but the MajorUpgrade Element "convenience feature" does this for you in an "auto-magical" way that makes sense for most purposes - using the mentioned property names WIX_UPGRADE_DETECTED and WIX_DOWNGRADE_DETECTED. Check the Upgrade Table of your compiled MSI to see how this works in detail. Here is a screen shot:
I wrote this other answer showing how to use another property name (YOURUPGRADEPROPERTY) as "ActionProperty": wix installer update process and confirmation dialog (the linked answer is not a recommendation, demonstration only). Just a link, probably not very useful for you now that I think about it.
Some Links:
http://forum.installsite.net/index.php?showtopic=13809
NOT UPGRADINGPRODUCTCODE evaluates to true on a major upgrade for custom action
It's not obvious whether you want to do this in the older installed product (which is presumably already shipped and therefore can't be changed without an update such as a patch) or in the newer upgrade install.
I'll also assume you've looked at the RemoveFile element and it doesn't meet your requirements.
The UPGRADINGPRODUCTCODE property applies to the older product being upgraded and uninstalled. If the file belongs to that installed product and you want to remove it only at uninstall with a custom action in that older install the condition on the custom action would be:
REMOVE="ALL" and not UPGRADINGPRODUCTCODE
but as I said, that custom action would need to be already in the older installed product and there's nothing you can do in your upgrade MSI to fix that.
If you are removing the file from the upgrade then the condition during an upgrade is only:
WIX_UPGRADE_DETECTED
It might also help to say where your major upgrade is sequenced. If it's early (such as around InstallInitialize) then the upgrade is basically an uninstall of the older product followed by an install of the newer product, and that might be related to the removal of the file, if that's what you're seeing.
I have built an msi installer using WIX. And as per the requirement I have to give an upgrade for next build. So, I checked about the upgrade, types of upgrade, its implementation steps and found Major upgrade will be suitable for us. So, as per steps I changed Package code, Product code and version number (increment the version) in project main .wxs file and generate the build which is upgrading properly (for that I checked in registry, Control Panel, etc...).
Major upgrade build is migrating features properly but user has no information whether installer is upgrading or doing the fresh installation. I am expecting an message like "The setup has been upgrading from v1.0.0.0 to v2.0.0.0. Do you want to continue" as user is going for installation.
Note: In my project I am having only 2 custom dialogs else rest all dialogs (e.x. Welcome dialog, EULA dialog, InstallDir dialog, etc...) are by default coming from WixUIExtension.dll.
I explored few links & blogs related to major upgrade but I didn't got proper solution related to this. Please share your valuable comments & what is the best way / practice for this.
You can detect a major upgrade by checking the UPGRADINGPRODUCTCODE property. You would then need a custom action to query MSI for the ProductVersion of that installed product. Finally you'd have to ask the user and proceed or abort.
How do you plan on handling silent installations? Just automatically proceed or require them to pass a property such as AGREETOUPGRADE=1 ?
When you do a major upgrade, assuming you're using the WiX majorupgrade tag, then the WIX_UPGRADE_DETECTED property is set. You could use that to condition a dialog to be shown. That property value will be the ProductCode of the older product, so you'd do something like MsiGetProductInfo (ProductCode, ....INSTALLPROPERTY_VERSIONSTRING....) to get its version. The dialog will presumably need a cancel to abort the upgrade.
You may run into issues because retrieving the ProductVersion may require elevation. In general, nobody bothers to verify upgrades like this because your customers are smarter than that. They know if the install is upgrading a new product or not and the fewer questions you ask the happier they are.
We have an installer that consumes a merge module. The newest version of the merge module includes downgrades to some files. When using the installer to upgrade from an earlier version we are having problems downgrading these files.
Initially the files from the merge module were being removed and not re-installed, but after reading wix major upgrade not installing all files I set Schedule='afterInstallFinalize' on the MajorUpgrade element. This resulted in the files with the newer versions being retained.
How can we change either our installer or the merge module so that these files are downgraded during an upgrade?
Well, in my opinion, the best way to approach this issue is to sequence the standard action "RemoveExistingProducts" to before CostInitialize standard action.
Be aware that this scheduling is not in accordance with the Microsoft recommendation at :
https://msdn.microsoft.com/en-us/library/windows/desktop/aa371197(v=vs.85).aspx
So, when you try to build your msi package, you might have to end up suppressing ICE error messages ,which if not suppressed, might prevent you from building.
There is an easy way to suppress ICE error messages in Wix . You can do that in the Visual studio IDE as well as when using the candle.exe to compile your .wxs project. The Wix documentation will give you enough details about this.
If you are wondering if its ok to go against the Microsoft recommended placement for RemoveExistingProducts, take a look at :
Downgrade File in MajorUpgrade
FWIW, I've talked to MS support in the past about having REP before costing to make upgrades work successfully, and at that time they said it was ok, while pointing out that it's also before MigrateExistingFeatures so if you migrate features during upgrades there'll be an issue.
What this means is that , if you have multiple features in your msi package and you want the exact same set of features to be upgraded by your upgrade package, then this approach might not work.
However, if you just have a single feature in your msi package, then this approach will work.
Also, be aware that placing RemoveExistingProducts outside of InstallInitialize and InstallFinalize has other consequences, in case there is an error during your upgrade, as RemoveExistingProducts is not transacted.
What might happen is that , RemoveExistingProducts will uninstall your old application and then the upgrade process starts the installation of your newer version of your product. However, at this point of time, if there happens to be an error installing your newer version of your product, then the upgrade rolls back and then you will be left with no version of the product on your system.
http://blogs.msdn.com/b/heaths/archive/2010/04/09/major-upgrades-with-shared-components.aspx
-The other option is to make use of REINSTALLMODE property.
You will author this property in your property table with a value of emus
REINSTALLMODE = emus.
If emus doesnt work, try with amus.
using amus is fraught with risks and should be avoided for the most part, except in exceptional circumstances.
https://msdn.microsoft.com/en-us/library/aa371182(v=vs.85).aspx
However, exercise caution here again.
REINSTALLMODE are caller properties and are usually set by the person performing the installation and hence its not a good practice to author this in the Property table.
However, there might be exceptional situations such as yours which might require you to take this approach.
-The other option i was thinking was to change the component GUIDs of the components in your Merge module.
However doing so would only work if the following condition is met:
-All the consumers of your merge module have RemoveExistingProducts sequenced very early in the upgrade cycle i.e they follow a method of ugprade where the older product is uninstalled and a newer product is installed.
So this might lead to re-sequencing of RemoveExistingProducts in all of your consumers.
Reason being, assume for a moment that you change the component GUID in the present version of the merge module and then you rebuild the latest version of the installer using this merge module. If RemoveExistingProducts is sequenced later in the upgrade cycle i.e after InstallFinalize, then it's a violation of windows installer component rules. You have two products installing the same file to the same location but with different component GUId's. Hence, its absolutely critical that if this approach is followed, RemoveExistingProducts is sequenced very early in the upgrade cycle.
Hope this helps.
This is my install execute sequence:
<InstallExecuteSequence>
<Custom Action='AlreadyUpdated' After='FindRelatedProducts'>SELFFOUND</Custom>
<Custom Action='NoDowngrade' After='FindRelatedProducts'>NEWERFOUND</Custom>
<Custom Action="SetInstallParameters" Before="actionInstall"/>
<Custom Action="SetUninstallParameters" Before="RemoveFiles">Installed AND NOT REINSTALL AND NOT UPGRADINGPRODUCTCODE</Custom>
<Custom Action="actionInstall" Before="InstallFinalize">NOT Installed AND NOT UPGRADINGPRODUCTCODE</Custom>
<Custom Action="actionUninstall" After="SetUninstallParameters">Installed AND NOT REINSTALL AND NOT UPGRADINGPRODUCTCODE</Custom>
<Custom Action="LaunchBrowser" After="InstallFinalize">NOT Installed</Custom>
</InstallExecuteSequence>
So I need to implement major upgrade functionality. Custom action called "actionInstall" is responsible for registering MySQL exe as service and runnig application, that performs all neccesary database updates by connecting to it and executing some sql scripts included in my installer.
"actionUninstall" is responsible for unregistering mysql service. Currently I have no any support for upgrading.
I need to implement major upgrade. So while upgrading I need to perform following operations:
copy and replace all installer files, except MySQL binaries (MySQL is treated as to be never changed). All files should be copied to program directory, that was used previously (it can be non standard), without any user confirmation.
Don't execute SetInstallParameters, actionInstall, SetUninstallParameters and actionUninstall. Instead, I will create another custom action for upgrade only. It will ony execute app to perform database upgrade
Don't display any setup dialogs (for example, destination directory selection, license agreement dialog).
My problems:
It seems, that major upgrade causes also executing Install and Uninstall - how to avoid it?
How to exclude some files (MySQL binaries) from copying to destination dir, but only on upgrade (on install they should be copied)
How to set destination directory for new files to the same as it was used by previous installation (it can be any directory selected by user on first install), without asking user to choose directory?
There are a couple of things to point out first:
The uninstall of the old product is not really "in" the major upgrade - it's a consequence of the major upgrade calling the uninstall of the old product that is already on the system. You can't prevent that uninstall happening because it is embedded in the older installed product and it will happen in a major upgrade.
A major upgrade is not a patch, or update as you seem to be trying to make it. It is a complete new product that replaces the old product entirely. It's an entire product that is available to new clients that happens to replace older products as part of installing the entire brand new product. This comment is really related to your remarks about not replacing the SQL stuff.
So you may not need to implement major upgrade capability unless you change the requirement about the SQL things. For example, if you simply wanted to update some files without doing uninstalls, then you could build an entire MSI file of the same Product, changing only the files you wish to update and incrementing the ProductVersion, a minor upgrade to install with msiexec /i ... REINSTALL=ALL REINSTALLMODE=vomus and there will be no uninstall of the older product - you've done an in-place update. But I don't think you need that.
Note your conditions on the custom actions! They already won't be called on a major upgrade (because of UPGRADINGPRODUCTCODE) or a minor upgrade (because of REINSTALL), so it's not clear to me why you're worried that they will be called during major upgrade. The designer of these calls anticipated this issue.
In your position I'd do this as a major upgrade:
Include the same SQL files as previously. If the binaries are the same they won't be replaced, or the same ones will be there afterwards, so why is there a problem? The install also works as a fresh install for new customers.
The custom actions in the old product being uninstalled won't run because of UPGRADINGPRODUCTCODE in the condition.
The same custom actions in the new product will run during the install, and I assume you don't want that because they will clobber the existing DB. In a WiX major upgrade, use a not WIX_UPGRADE_DETECTED condition (as well as the others) to prevent CAs from running on its install.
If you want to change or suppress dialogs because it's a major upgrade, then use WIX_UPGRADE_DETECTED to alter the flow or suppress them. Don't delete them because, again, you're doing a major upgrade not a "patch".
If you want to install to the same location, it's sometimes useful to write that install location to the registry with the WiX remember property pattern in the older install so you can recover it later. I susperct you didn't test major upgrades before you shipped the product, so you'll need something else. Find a component Id that's in the directory you want to use, then use a WiX Component search to initialize a property that is the directory name.
For the future, make sure that your CA conditions allow a straight uninstall to work properly, and a major upgrade is essentially the same as a fresh install, and replacing or updating binaries doesn't really matter, so make sure new cuatomers can use it. Also, if you need to remember the install location of data files then your design may be incorrect and I suspect your data is in the user-browseable Application Folder. Data should be in a data folder (such as AppDataFolder) so you don't need to worry about its location on an upgrade AND to help enable limited users to run your app because they cannot update files in the Program Files directory.