I have a wix burn bundle with Visible="yes" for all MsiPackage elements. After a new install or upgrade, as expected each MSI package appears in Add/Remove Programs, including an an entry for the bundle. However, when I do a repair of the bundle after an upgrade, all MSI entries unexpectedly get removed from Add/Remove Programs. If I do a repair after a fresh install, all entries in Add/Remove programs remain intact.
The upgrade that I am doing is not actually from a previous version of the bundle. Rather some MSIs are already installed and the bundle upgrades some of these MSIs. This will be the case for our customers because we have shipped MSIs for a long time, but this is the first time we are planning on shipping a burn bundle.
Has anyone else seen this unexpected behavior with repair?
I'm using Wix Toolset version 3.10 and I have a managed bootstrapper application. I am not sure what I could be doing wrong with the repair in my managed bootstrapper application to trigger this problem. Perhaps this is a bug in burn?
The answer is no. No one else is likely likely to see this exact problem on repair. This is because the problem was caused by very specific and peculiar bug in two of our MSIs.
For example, one MSI had the following entry in the RemoveRegitryTable...
RemoveRegistry = RemoveIconRegKey
Root = 2
Key = Software\Microsoft\Windows\CurrentVersion\Uninstall\[UPGRADE_1]
Name = -
Component_ = RemoveIconRegKey
... and, during a repair, UPGRADE_1 was not set.
Although it was a bug, we had not caught this problem for years. We are just now switching to burn and the problem was triggered by the way in which burn does repairs. Specifically, burn sets the REINSTALL property. That is, only when the REINSTALL property is specified does the RemoveRegistryValues action get re-run for components that are already installed. Although the action is re-run, the UPGRADE_1 property is not set during a repair, causing all of the 64-bit Add/Remove program entries to be removed.
Also, I realize now that there is no way that burn could wipe out all add/remove program entries while a single MSI is being installed. I'm pretty sure that burn hides add/remove program entries by passing ARPSYSTEMCOMPONENT=1 on the command line to each individual MSI that is to be hidden.
Related
I am attempting to make sure certain software does not exist before installing the newer version. Long story short, vendor requires me to do so, and although they recommend me to repair after install, that causes other issues such as undesirable restart (trust me I tried /norestart and I have even tried to modify the stored msi package to make sure it does not restart) but over all it just gives us soo much headache without the result we want.
So I tried to simply uninstall this software ahead of installing their newer one since that seem to have higher success rate without unnecessary issues.
Now I am accomplishing this by running batch file via ExePackage (with WiX toolset) with Vital="no". I have to do Vital="no" because when the older installer does not exist and if I call msiexec /x, it returns the error stating
this action is only valid for products that are currently installed
When the older installation exists, it works fine, but when it does not it errors out.
Now Vital="no" works fine, but I would prefer to suppress the error with msiexec /x if I can.
Is there any known way to solve this?
In order to solve this problem, I checked the uninstall keys and only called msiexec /x on products that were listed. Though in my own case, we were switching installer tech (too many MSI bugs...) and were uninstalling older versions of our own.
Installation State: You can use VBScript to check for the installation state of a product if you know its product GUID (replace the sample GUID here):
Dim installer : Set installer = CreateObject("WindowsInstaller.Installer")
MsgBox installer.ProductState("{6C961B30-A670-8A05-3BFE-3947E84DD4E4}")
There are a number of possible installation states. Here is a more comprehensive script to check product installation state. Check section 7 here.
Major Upgrades: I assume you are aware of how major upgrades work? (uninstall of existing installation and install of newer version with options for what order this happens in). They can in reality uninstall any other MSI package on installation via settings in its Upgrade table. This includes even competitive products (a bit mad one would have to say). You can - however - not install them again easily from within MSI for a number of technical issues. You could install them via a Burn setup.exe bootstrapper (which I think you use).
I am using Visual Studio 2013 installer to package my application. I then make a copy of the MSI, open it in Orca and remove all the dialogs to create a silent package. So I have two MSI's that should be the same other than one is silent and the other is not.
When I upgrade from a previous version (built in the same way) using the non-silent package, everything works perfectly.
However when I upgrade from a previous version using the silent package, it all works apart from I am left with 2 entries in Add/Remove programs. It all works though but looks ugly for the client. When i uninstall the latest version, Add remove programs still has the previous version listed in Add/Remove programs although actually the latest version is still installed.
As I say, the non-silent package works perfectly well, which leads me to think I must have everything setup correctly in Visual Studio and Orca must be doing something I didn't intend.
Any help would be much appreciated.
If you have two entries in Add/Remove Programs then the upgrade didn't work. A common reason is that one of the installs is Everyone and the other is Just me. If you delete the dialogs then you have altered the behavior that sets the ALLUSERS property, and your upgrade could default to Just me. In the absence of a decision to use one of these choices VS setups use ALLUSERS=2 which is defaulting to a per user Just me install, that's the likely reason. Elevation is involved too - VS setups would rather your MSI did a successful Just me instead of a failing Everyone if privilege state is not clear (and in MSI setups it often isn't).
You might need to go to the Property table and set FolderForm_AllUsers to "ALL" and ALLUSERS to 1 to force a per machine Everyone install.
How silent do you want it to be? If it requires elevation to install successfully then you need the elevation dialog to be shown or the install will fail silently if you force a per machine Everyone install.
When I try and apply a minor upgrade to my application, I launch the installer and (depending upon the combination of settings I try) I get either a:
repair/remove dialog
prompt for the install directory
I don't believe I should get either of these prompts. I'm mostly expecting the installer to automatically apply the upgrade and not prompt for anything. I think I'm doing everything correctly in the Visual Studio setup project:
upgraded the version from 1.0.0 to 1.1.0
left the product code the same
updated the package code
left the upgrade code the same
launch the installer with the parameters REINSTALLMODE=vomus REINSTALL=ALL
I've tried just about every combination of codes/flags and techniques, but cannot seem to get the update applied.
Any ideas of what else I can try?
To get it to work I:
upgraded the version from 1.0.0 to 1.1.0
left the product code the same (said No when prompted by Visual Studio)
updated the package code (Visual Studio did this automatically)
did not change the upgrade code
launch the installer with the parameters REINSTALLMODE=vomus REINSTALL=ALL
Just as I had indicated in my question, and it seems to be working. I can successfully apply an upgrade. However, when I run the installer I am still prompted with a repair/remove option. But, that's a different question I guess.
Just first things first: Are you sure you haven't re-used the package GUID in both MSI files, or at some point during deployment work and testing?
Try rebuilding both MSI files with new GUIDs to "de-couple" them from any existing cached versions and then try test installing again. Change both the package code and product code. Better yet: test these new versions on a clean virtual machine to ensure a proper test environment unaffected by past sins. Your developer system could have gremlins in its Windows installer database due to package guid clashes. If this is the case package installation becomes total XFiles - the strangest things can happen.
More details:
If the package GUID is the same for two MSI files, Windows Installer will treat them as the same file by definition - no matter what they contain. This can cause all kinds of strange problems that are hard to clean up and debug. Note that this can happen even if you just forgot to update it once since installation of an MSI will cause it to be cached on the system in the C:\Windows\Installer folder (this folder is hidden and protected). This cached copy will be re-used if an MSI file with the same GUID is launched (at least this was the case for earlier versions of Windows Installer - there could be fixes for this now).
If you are using Installshield you should enable the "always generate packaging GUID" feature to ensure this never happens. Package GUID should always change for every single build - there is no reason whatsoever to keep it hard coded. I believe WIX takes care of generating the package GUID automagically, unless you specifically override it.
I have an Installer created with WIX that installs a bunch of DLL and Config files. Once the installation is complete, obviously there are times when I would like to update JUST the DLL files and leave the configs as they were.
I've looked at the NeverOverwrite="yes" option and that looks promising, however I am now running into this issue. When I try and re-run my installer after an installation is complete, I get this error.
The problem is that I do not want to mess with Build Numbers or Product Ids. I just want the installer to re-run and overrwite the necessary DLL files. Does this make sense?
If you recompile to update the dlls you should really think about updating the versioning in your installer. If you have a build process that updates the build number every time you compile your dlls and your installer this shouldn't be a problem.
The reason you are getting the error is because the Product Id and version numbers match, but the package codes differ. To resolve the error you have the following options:
Update the version number and treat it like an upgrade.
Change the product id (and version) and treat it like an upgrade.
The product id and version can match if you set the package code, however this is not really recommended, especially if you are modifying the files in the installer. If you do set the package code to match the previous installer, you will get the maintenance dialog and if you do a repair or modify, I'm not sure if it will use the cached MSI or the recompiled MSI when performing the repair, so I'm not sure what results you can expect.
Like BryanJ says, the error indicates that you are installing a new package which has the same product code as a previously installed package.
The solution is most likely to just set the product Id attribute to *. You only need stable product ids when you want the ability to do minor upgrades.
A minor upgrade does not allow any reorganization of the feature-component tree, and AFAIK only has the advantage of being quicker for huge installations. We just do all upgrades as major upgrades, which are easier to manage.
We have an installer solution written in Visual Studio 2005 Installer; that calls a C# custom action and we have hit a known issue, regarding the fact that on an upgrade - the old install code is run and not the new code, because Windows is running a cached version of the custom action dll. We know this and although not over the moon about it - we have moved on.
When we release a new version of the installer and a user runs it, we now want it to check to see if an ealier version is installed - if there is one; we want to display a message telling them that they have to remove the old version via Add/Remove Programs. We know if they do a manual uninstall followed by an install, then all is fine and dandy - BUT it doesn't matter how many times we tell our users, via documentation; that this is what they have to do - they will still try and just run the new installer, without removing the old version first.
Therefore, we would like to put up a message and thus force them to to what they are told !! I've seen some installers do this ( though of course not sure what installer package was used to create these ). We only have VS 2005 and of course orca !!
Cheers,
Chris.
This can be done through a custom launch condition:
create a search which determines if the old version is installed (you can search for a component, registry entry or file)
use the search property as a custom launch condition
For example, if the search property is OLD_VERSION, the launch condition can look like this:
Condition: NOT OLD_VERSION
Description: An older version was found. Please uninstall it using "Programs and Features" in Control Panel.
When OLD_VERSION property is set to a value (an older version is found), this launch condition will show the message and stop the install process.
This doesn't quite make sense. Have you remembered to change the package GUID in your new setup? The package GUID identifies a specific setup file, and if two MSI files have identical GUID they will be treated as the same file regardless of whether they are or not. This could trigger a cached version of the MSI to be invoked and all sorts of hell breaks loose.
I would recommend reading up on "major upgrades" which will allow automatic uninstall of the existing version before the new version is installed. You also need to make sure you understand the basics of the technology before deploying to the wild. You must NEVER use identical package GUIDs for any MSI files. It's practically always wrong, and will lead to very mysterious problems.
I can't write up the whole major upgrade solution here, but basically it involves authoring the "Upgrade" table of your MSI to detect versions to uninstall. You need to change the package code, product code and version number (only 3 digits matter) and keep the same upgrade code (two MSI files with the same upgrade code "know" they are related - i.e they are from the same product family). Check MSDN for samples of major upgrades.
NB! If you have deployed MSI files with duplicate package GUIDs to your developer machine, it could have stray installs that must be cleaned up with MSIZap or similar. Use caution, or better yet test your new installer on a clean test system. Developer systems are full of junk and not generally good for MSI testing.