I'm doing an installer, using wix v3. I have two installers. I installed my app with the first one and then I want to update it with the second installer.
I think that I'm missing something since I cannot install the product and then run an update (with other installer), If I execute the same version, I could see the maintenance windows, it recognize that the product is installed. The problem is with other versions.
I think that these could be because of the value of the Installed property. What thing should I do to have these property set correctly? I'm installing the product for all users...
What could be wrong?
See How to implement Wix installer upgrade which provides a number of detailed examples.
I have already done it. It works for the same product Id, but when I change the product Id, it recognize the upgrade code ((I'm sure of that because I set a property), but the Installed property is set as false.
I will use a property to notice the different version, something related to the last answer.
Thanks!
Did you set your WIX project to be able to detect it's an Upgrade ?
Have a look at the upgrade part of the basic WIX Tutorials
Related
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 got a problem. I want to upgrade my app during installation process, but I run into problem with versioning. I use version number in format e.g. 5.5.789.0, some new version has version number in format 5.5.12.1. I know that installer only works with first three numbers from version so MajorUpgrade is not suitable for me. New version would not be installed in this case. Is there a way in which I can check versions in some custom action and plan upgrade from there? I cannot change the versioning as app building goes through some automatic post-processes that also works only with first three numbers and it is not possible to change that behavior.
Thanks for suggestions.
EDIT:
I am using WiX#.
It's not obvious to me why you can't use the WiX majorupgrade element. The settings would be AllowDowngrades=yes, maybe AllowSameVersionUpgrades=yes.
Using Schedule=afterInstallValidate is (as the docs say) removes the old product entirely before installing the new upgrade.
I have a managed wix bootstrapper and I noticed that I can provide a url for an updated version of the bootstrapper for upgrade detection. However it seems this only runs if my bootstapper has been installed before. Is there any default way for burn to detect a newer version of the bootstrapper before installing the current version? What I would like is if a customer has a copy of a legacy bootstrapper and runs it to install a new machine that the user is provided an option to download the new bootstrapper and run it instead. I assume I could code all this up from scratch in custom bootstrapper but wanted to be sure that I wasn't reinventing the wheel. It seems like there would be given that most of this is already implemented with the update detection.
You can always check the reg keys for product version and compare it with your latest.
From the docs, http://wixtoolset.org/documentation/manual/v3/xsd/wix/update.html, this feature is not available yet and you would have to build it into your custom WPF bootstrapper application.
After further testing and investigation it looks like I was incorrect about how this works. The detectupdateBegin event does get called even if the bundle hasn't been installed before. You can either allow Wix to consume an atom feed using the app syndication format. If you use this format then the engine will return the latest version in the feed. Otherwise you have to roll your own update service and put the call in the detectupdateBegin event handler. Be sure not to set the result to Ok otherwise the engine will look at your service url and try to process it like an app syndication feed and return an error.
One you detect an update you will need to call Engine.SetUpdate and then call Plan with InstallAction of UpdateReplace.
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.
The execution of a wix package from a bundle outputs "error 1316: The specified account already exists" during upgrade. How can a windows installer output this error code? I'm afraid there isn't much documentation about it.
We previously released a product consisting of a single msi package, and now we are preparing an upgrade which consists of a wix bundle containing a new version of this msi package. The product code and filename between the original msi package and the update haven't changed.
Edit: The msi package for now doesn't support upgrade. When the user needs to upgrade (whenever it's a major upgrade, minor upgrade or small update), he must first manually uninstall the previous package...
Edit 2: I just removed the references to util extension for compilation and the installer seems to work fine... I still need to fully test it though.
Like MrFusion, I ran into this problem with the uninstall/install of another program. Unfortunately, the link in that answer is no longer valid, and redirects to a page that lists many easy fix solutions, except for the only one that will help. That one, "Program Install and Uninstall", is currently available at: https://support.microsoft.com/en-us/help/17588/fix-problems-that-block-programs-from-being-installed-or-removed
It solved the problem for me.
I had his same issue and since win10 doesn't allow you to run the fixit tool from the web, I did the following hack to uninstall Asus Smart Gesture on my Windows 10 laptop.
You need to fake the MS site into thinking your pc isn't Win10. I installed a Chrome add-in that allowed me to change the user-agent of the chrome browser to thinking I was IE9 and previous version of windows: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
This allows you to see the fixit button and to download a portable version of the tool (in case you need to use it on non-networked clients)
I downloaded and extracted to my downloads library in a folder called fixitp.
If I run the exe directly, I get some nasty script error. What I did to get around that was to navigate to the Resources folder and then to the Troubleshooters folder.
I ran the Program_Install_and_Uninstall.diagcab which run and allowed me to uninstall successfully the Asus SmartGesture program.
I then installed a fresh version of ASUS's Smart Gesture from their site.
I suspect that any installed app that you can't uninstall can be resolved by this same process - just haven't run into any other that this on.
Good luck.
An upgrade MSI requires the MSI to have a new ProductCode, an incremented ProductVersion (in the first 3 fields) and the same UpgradeCode. So it's not clear to me that you're actually getting an upgrade, depending on what the Burn part thinks you are doing. It can't do an upgrade because you have the same ProductCode. (You need a MajorUpgrade element in your MSI to do a proper upgrade). So there is some doubt as to whether you're getting an actual full upgrade. If your intent is to replace the installed MSI with a full upgrade, and a higher versioned product then use MajorUpgrade.
So Burn may have decided to do an in-place update by reinstalling the MSI file (and that's more like a patch than an update), and that's relevant because you don't say whether you have any custom actions or WiX util functions (they are still custom actions) that create a user account. If you do, then the most likely reason for your error is that Burn reinstalled your new MSI as an update by reinstalling the MSI file, and some custom action simply ran again, and yes, that user is still there because there has not been an actual uninstall that would delete it. Or the ProductVersion of your MSI is the same and you got a maintenance mode repair, so a custom action would run again.
I'd get a verbose log of the upgrade to see exactly what's going on.
There's a lot of guesswork here because you say you want an upgrade but your MSI isn't built to actually do an upgrade, and you don't say if you have WiX util User in there to create a user account. You also don't say if you have incremented the ProductVersion of your new MSI either, so again that results in more guesswork as to what Burn might do. The verbose log would show whether it's a custom action issue or something else, what kind of update (if any) that you're doing.
I ran into this recently.
For me this worked for me by keeping the names of both the older version and the newer version of the installer same.
No idea why it works, but some of the best practices while working with msi is to keep the name of the installers same.
A couple of links to support the case –
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/KB2918614-td7596942.html
https://community.flexerasoftware.com/showthread.php?189045-Upgrade-failed-with-Error-1316&highlight=error+1316+account+already+exists
I had the same issue uninstalling another program. This Fix-It solved the problem for me: https://support.microsoft.com/en-us/mats/program_install_and_uninstall/en
Update note: it's no longer necessary to emulate an older user-agent on Windows 10 to download the fix-it file.
Update 2: As Chris Johnson mentioned, Microsoft has discontinued Easy Fix, so the link above does not work anymore.
You probably need to change the 'packagecode' (note: NOT 'ProductCode') for the MSI. You'll find it in the Summary Information Stream.
Just encountered this myself when trying to create an Upgrade MSI package. Using Orca to change the 'packagecode' fixed it.
For me, that happening with nodejs when I was trying to uninstall it. What solved in my case was downloading the same version of nodejs that was installed (8.11.1) and uninstalling that from msi installer file.