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.
Related
I have a WiX bundle that includes the .NET core runtime installer and my product MSI. If I don't tweak anything, I get two entries in the Add/Remove Programs list - one for the bundle and one for the product MSI. I have tried two approaches of showing only one but I run into some issue either way.
Approach #1 - Set MsiPackage attribute "Visible" to "no" in the bundle. This leaves a single entry in Add/Remove Programs (for the bundle).
The problem here is if they do an initial install with the bundle, but later only install the MSI to upgrade, they get 2 entries in the Add/Remove Programs list - the original bundle one and the new product one.
Approach #2 - Set Bundle attributes DisableRemove and DisableModify both to "yes" in the bundle. This gives a single Add/Remove Programs entry - this time for the product MSI, not the bundle.
The problem here is the following sequence:
Install bundle version 10
Uninstall ARP entry (product MSI)
Install bundle version 9
That third step fails because the system sees a version 10 bundle still installed.
Our bundle is 30MB and our product is 3MB. I don't want to have to have every subsequent update download another bundle when I know .NET is already present and not necessary. So what approach can I use to install the bundle originally but later update with an MSI and not run into the issues above?
EDIT: The only approach I can think of is to have a custom action on uninstall which detects whether or not the MSI was dispatched via the bundle (as opposed to standalone) and if it is not, it then uses something like MsiEnumRelatedProducts() to find the product guid for the bundle and inline uninstalls that. Seems super messy and I'm not sure if it would even work or if that invocation would hit some kind of "installer already running" error.
Setting ARPSYSTEMCOMPONENT = 1 in Property Table of MSI installer(or from command line) will prevent it from displaying in Add or Remove programs. So, Your first approach should work after this change.
I think the simplest solution here is to never distribute MSIs and create two versions of the bundle - one that only contains our package, and the other which contains our package plus the .NET runtime. Always mark the embedded MSI as visible=no and have the bundle's entry show up in ARP. This ensures bundles always update bundles, ARP shows the correct version, and that nothing ever gets left behind on an uninstall.
I tried to implement a custom action on MSI uninstall to query the bundle's Upgrade Code and manually remove it. Unfortunately, WiX bundles do not show up to the system as normal products. So while I could manually parse the registry, the more robust APIs like MsiEnumRelatedProducts() cannot be used. Therefore, I think the bundle-of-one is my best solution at this time.
The old version of the setup was created with InstallScope="PerMachine".
The new version is intended to have InstallScope="PerUser"; it also needs to use the same registry keys as the old version creates.
The problem is that whatever values are stored under these registry keys during the upgrade will be overwritten at the end with the initial values stored by the old version. Even deleting these keys manually before the installation will make them reappear (with the wrong values) after the installation process.
I have tried creating a custom action and specifically delete these keys, but the result is the same.
How can I ensure that the old version does not interfere with the installation process of the new version allowing to delete the old Registry Keys and re-create them?
What I found to be working:
Performing a REPAIR immediately after installing the new version will yield the correct results!
Uninstalling the old version manually before installing the new one will not remove the keys, but will allow to overwrite them with the correct values.
You should define what kind of upgrade you are doing, and if it's a major upgrade then where is it sequenced in your major upgrade element, although...
Probably the main issue is that cross context major upgrades aren't supported by Windows Installer, so if you are doing a major upgrade you will end up with both products installed. That's not an upgrade, that's most likely just a collision. So assuming that you want only one of them to be installed at the end of all this, you will need to uninstall the older per-machine installation and then install the per-user. As to why the uninstall of the per-machine product doesn't remove the registry keys, there are many possible reasons, such as they were created by the app not the MSI, or the component was marked permanent, or the component has another client product on the system - a log of the uninstall might show what's going on.
I have to add this as an answer, too long as a comment. I will "evolve" it once you provide more information:
Why do you want to switch to per-user installation? In the MSI world this is not an ideal way to deploy. An application is usable per-user even if installed per machine. With a per-machine install you simply add the ability to write shared settings that should not be overridden by a user. And your application is easier to upgrade, uninstall, patch and manage overall.
Here are a few more links to explain some of the problems with per-user setups. They are real, I am only trying to warn people what problems they are most likely going to face (almost certainly going to face):
Having an issue with WIX upgrade
Understanding “Per-User” or “Per-Machine” context for application Setup packages
Are you deploying HKCU or HKLM keys? I would not recommend writing any HKCU values from your setup, they should be written by the application itself. A setup is for writing to HKLM and other places that require "elevated rights". It should never be used to write user preferences. There will be interference when you do upgrades (as you have experienced).
Where is the registry data you speak of stored? In a single MSI component or several? Is there anything else in that component that still needs to be installed without the registry keys? If you can, please add your source WiX file so we can see for sure.
I am sure that we can make all these problems go away if you follow our advice precisely. You are facing a very common MSI problem.
Let me attempt a tentative answer without having all the information:
Remove all HKCU registry information from your setup (if you can).
Update your application to write these HKCU values itself, and ideally write to a brand new location in the registry instead of the old one. For example HKCU\Software\MyCompany\MyApp\5 instead of HKCU\Software\MyCompany\MyApp. This "decouples" your old and new state, and you got room to maneuver and clean up things.
Making your application write the HKCU keys is not a hack, but the right thing to do. It will make your application much more robust and generally easier to QA for yourself and your team. You can "wipe the slate clean" during testing and start over without a reinstall - in order to focus on application testing.
Put any remaining HKLM settings in a single WiX component and set a good key path that will never be modified or deleted by the user or any other process. For example: HKLM\Software\MyCompany\MyApp\5\MyAppHKLMKeyPath = 1
If you discover that you have to override a value for each user (in other words change something for every user in HKCU), you can do this with this approach which combines what the setup does with the application itself: http://forum.installsite.net/index.php?showtopic=21552 (if this is important, please read the whole, linked thread).
I simply need to install multiple instances of my application saving them in different folders, with no shortcut on desktop.
In other words, when the App is already installed in a Folder, if I double-click the .msi file once again, the installer shouldn’t ask me if I want repair or remove my App, but it simply should permit to install it in a new folder.
How can I solve this problem?
I used to work with this kind of installations before, and I would agree with #Nikolay - it is rather an exception, than the rule when it comes to Windows Installer based installations. Component rules are often tricky to follow, and multiple instances aspect adds some complexity on top. So, think twice before you go this road.
Being complex, it is still possible. Years ago I published the article of how to start authoring multiple instance installations with WiX 3.6. Note that this version of WiX simplifies it significantly. It's not a short read, so here is a quick digest:
You won't be able to achieve the "install each new instance with double-clicking MSI file" behavior. You have to have a bootstrapper - something that passes correct command line parameters to msiexec.exe.
Don't try to support unlimited number of instances - try sticking with reasonably big number. Do you imagine someone installing your app 10 times on a machine? 50? 100? Make a sane choice - this will be the number of your <Instance/> elements.
Although you only have to decorate non-file data components with MultiInstance attribute, I don't think it will break if you add it to all of your components.
Although I explained the patching of multiple instances in that post, I would only use it in production if I had no other choice.
What you are asking for is not normal in Windows. Normally, each program (product) is installed only once. I.e. each installation package has it's ID (called "ProductID"). If that ID already registered in the system as installed, the system will not allow you to install the second product with the same ProductID, but start change/remove.
What you can do:
Don't use Windows Installer (and WIX), use ZIP for example, or some self-extracting archive, or some other program which does not register installed product in the system.
Use command line to change product id before installing if you want MSI and Windows Installer for whatever reason. Try googling on "use transforms to install the same MSI multiple times". Thus you can have the same MSI per-transformed before installation, so that it looks as a different one to the system.
Install per-user, if that's good enough for you (i.e. don't install to Program Files, install to user folder)
Maybe there are other options...
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.
It's a WiX MSI installer and each time I uninstall and reinstall it in my virtual machine environment the size reported in Add/Remove Programs gets bigger. It's up to 200MB now when the installed files are only just over 30MB. Any idea how this could happen and what I might be doing wrong?
Edit: Not using any custom actions, and I don't have anything for the uninstall, just assuming that WiX takes care of cleaning up after itself on uninstall, and it seems to. From what I can see, it's the reported size that is incorrect, I can't find any duplicated files or anything.
Can you put your ARP entries ? Also, how do you handle the RemoveOnuninstall attributs in the wix elements?
Do you have CustomActions that write data? Do you erase that data, when uninstalling ...
Fill in the most details as possible.
I found this post, then that will explain what's your situation here, and the link to how the arp sized is calculated or almost ;)