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.
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 had an MSI with a CA type 1. Later on, I realized that CA had to be changed so I updated it and created an MSP.
Q1: If I install the MSI and then apply the MSP, I don't think the cached MSI (one in Windows\Install directory) contain the updated CA, right?
Q2: If I uninstall this MSI, does the installer uninstall the MSP first and then the MSI?
Q3: Which CA would be performed during uninstallation? An updated CA or the original CA? Or an updated CA first and then the original CA?
Thanks in advance.
In (typically) the \windows\installer directory there is the cached MSI and any patches that have been installed for that product. When some installation action is performed the cached MSI and all its related patches are "merged" to create the view of the actual currently installed patched product, so:
So Q1 doesn't really apply because nothing is done with the cached MSI on its own. If you look at it with Orca it won't reflect the patch, because that's in a separate MSP file.
Q2: There is no first and last because the (MSI+Patches) is what is uninstalled, followed by clean up removing the files that are no longer needed.
Q3: There is only one CA in (MSI+Patches) and that's what is called.
PhilDW has attended to your specific questions, maybe I can make a few guesses as to what the underlying problem really is.
Is this a minor or major upgrade MSP? A minor upgrade patch can be used to "hotfix" errors in the installed MSI's uninstall sequence - if that is what you are really asking. I have done so many times, and when you install the patch first and then uninstall, what is running on uninstall is what you included in your MSP - the new CA - provided you installed everything correctly (command line, etc...). The MSP is merged to the cached MSI - as Phil states - at runtime. What I am a little fuzzy on, is how any applied transforms are handled - this is something I have never had the time to test. Are you using transforms?
This approach is frequently used when you discover an error in the installed setup's uninstall sequence which prevents a major upgrade from running correctly. In a regular major upgrade the old custom action may or may not run from the old setup depending on how it is conditioned (see link for some conditioning cheat sheets), but typically it either runs undesirably, returns an unexpected error that triggers an undesirable rollback or the whole custom action crashes, causing a failed major upgrade (or failed uninstall).
The above yields a catch 22 situation where your existing install appears un-uninstallable and un-upgradeable - but a minor upgrade can come to the rescue (a regular MSI installed as a minor upgrade should also work - it shouldn't need to be delivered as a patch, provided that you properly re-cache the new MSI from the command line - a patch is merely a distribution mechanism for an upgrade that is already working).
A major upgrade patch (MSP), on the other hand, will not allow you to fix errors in the uninstall sequence of the existing installation since it triggers the uninstall sequence of the pre-existing install and just tells it: "uninstall yourself" - as part of the major upgrade operation. When this happens, then the old CA is used - which is embedded in the cached MSI for the old setup. It is the old setup running - unchanged.
It has been over a decade since I made a major upgrade patch - I find them pretty bad and I avoid them if possible. There are too many problems - and honestly: a few serious logical flaws (for example the fact that the product you are trying to patch may already have been uninstalled - if you schedule RemoveExistingProducts early - see below - a rather ridiculous error, one would have to say). I have never made a major upgrade patch using WiX, but I tried with Installshield and briefly with Wise. In order for them to run at all, you have to set the uninstall of the old version to happen after the install of the new version (so the old version isn't already gone by the time you try to patch). This means RemoveExistingProducts must be late in the InstallExecuteSequence - which makes the setups vulnerable to component referencing errors (another common problem).
UPDATE: I should also add that my major upgrade test - done many, many years ago - also had problems with feature state migration (MigrateFeatureStates) - the patch caused all features to show up in an unknown state. To this date I have never had the time to figure out exactly what happened, but I think it may have been my own doing. I did something funky with the Preselected property (I think it may have been related to a merge module doing something stupid - and I tried to "fix" it - with another fix that didn't fix anything, but caused new problems - and such forth and whatnot :-) - deployment is fun). Just reporting the failure, and whatever intel I have - not claiming to have any solutions. There were also other problems - but most of them were Installshield specific I think. WiX might do a lot better. Wise was sensationally good for minor upgrades (they really did work), but I never used Wise for a real major upgrade.
A typical major upgrade custom action problem is that the custom action is erroneously conditioned and will run in both the old version's uninstall, and the new version's install. There are many modes to test your conditions in, and you will be surprised if you take the time to do so: install, repair, modify, uninstall, patch, etc... And you will often find that the custom action runs unexpectedly on modify or repair operations or similar. I linked to a couple of cheat sheets for conditions above, here it is again: Is it possible to run a custom action only in repair mode.
UPDATE: And a common patch problem is that custom actions may run unexpectedly because they are not conditioned with NOT PATCH. Rant: I wish patching would be its own thing in MSI and not just a delivery mechanism for a regular update, and that it would target files only and have its own installation sequence (like admin install has). This would allow "targeted patching" and small hotfixes for huge products - which really need some working, down-to-earth patching that is not overambitious and over-complicated (which is what patching in MSI currently is - in all honesty).
Advice? Use a minor upgrade patch or a regular minor upgrade (not delivered as a patch) to fix the uninstall problem, and then proceed to use your normal upgrade approach. It should be possible to deliver all this in a WiX Burn bundle - but I have never had time to test it.
My 2 cents? Forget patching if your product is small, and just use a regular minor upgrade MSI. If your product is huge, then use a patch package (or your download bundle will be a lot larger than necessary). Be aware that your future setup bundles should also contain the "hotfix" patch / MSI to allow users with older installations to fix the uninstall error before installing the latest version. A little clunky, but it should be manageable. If your old setup has a working uninstall, but fails as a major upgrade (because of an insignificant error in the uninstall sequence making the whole process fall over), you can uninstall the old setup with a regular uninstall command passed to msiexec.exe and then install the new version afterwards (avoiding the major upgrade scenario by performing a manual uninstall first). I haven't tested this with Burn yet.
I used a wix generated msi file to install a software. Installing the software works fine, but sometimes there are some problems during uninstall.
All the files in "Programm Files" are removed as expected but after the uninstall, some data still remains on the system:
the app entry in "Programs and Features"
the installer in "C:\Windows\Installer\"
(and some registry entries which point to the two things above)
The problem is: as long as those data is on the system, it's not possible to reinstall the same version of the software. The installer shows the "Repair / Remove" action. None of them are working anymore.
But why does the installer not remove those files/entries?
What could be the problem?
Just some notes: when performing a MajorUpgrade, the new installer removes all the old entries. But this is not a solution.
Ans yes, all those registry entries and files can be removed by hand. After that a reinstall is possbile, but this is also no solution for the users.
This doesn't make much sense, primarily because installs and uninstalls are complete transactions, so that if an uninstall fails it will roll back and the entire product will still be there. It won't be a partial uninstall where some things stay and others are removed. Some things to look at are:
Do a log of the uninstall with msiexec /x {productcode} /l*vx [path to log file] to see if something shows there, for example if it finished successfully.
The \Windows\installer directory is full of msp, msi, mst files, so it's not clear what you mean about "the installer" being there because lots of cached installer files are there. Yours might be there too, I agree, if there is an entry in Programs and Features. That just means that there is still that product installed.
It's not clear why you mention upgrades, or what the entire scenario is. However you would get to your current situation if you had two installs where one was installed over the other incorrectly. Uninstalling one could remove all the files but leave a product behind.
Your system may no longer be clean if the same ProductCode has been used for multiple installs and testing, or you've attempted to clean things up with a tool like MsiZap. Start with a clean virtual machine every time, and see if you get the same issue. If this is happening on one test machine that might be scrambled due to repeated testing, then it could help to give your setup a new ProductCode and a new UpgradeCode.
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.
i am new to Wix toolsets. i have successfully made my first installer in Wix but now i am confused about my software updates which usually are minor.
in my installer i want to check if user have any older version installed then i want to show him three options ;
Modify: which would install new version.
Repair: which would repair previously installed product.
Remove: which would remove the installed product.
for Modify i can simply show InstallReadyDlg as next dialog which would then uninstall previous version and install new one.
But i am unable to find out that how can i trigger uninstall or repair of previously installed version.
Any hint would be highly appreciated.
Note: i know how can i show these options and how to detect if user has any older version installed.
That's not the way things are usually done because:
Modify is universally understood in this context and dialog to mean adding or removing features.
You can't properly do an upgrade from a dialog of an already installed product that is going to be removed. In other words your plan most likely won't work because you'll need to browse to the new MSI (web site? CD?), then launch it from your modify dialog (how, when you have the current product dialog showing?) and then attempt to upgrade a product with a dialog showing.
So nobody does installs with that behavior, and nobody expects that non-standard behavior, and it has a good chance of not working.
Having said that, that's why you get modify/repair/remove for free from the built-in WiX UI dialogs that you just include, so there is nothing you need to do to get repair, remove, or modifying installed features to work. It's all there.
Installed products are upgraded with patches (for small fixes), and also major upgrades, where you just build a new MSI as a full new product and include a MajorUpgrade tag so that it will remove the older version if there is one installed. Just install the new product (from CD, web site or whatever) and it's always a fresh complete install that upgrades and removes any prior version because of that MajorUpgrade element.