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).
Related
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.
I am using WiX to install a executable and I have used ManagedBootstrapperApplicationHost for CustomUI.
Is it possible to get the name of the feature being installed at the time of installation ?
If possible then how can we get the name of the feature ?
Any help would be appreciated.
Thanks.
Features aren't installed one after another. For example if 3 features are being installed, each with 10 files then the InstallFiles action will install all 30 files at the same time. Same thing with registry entries. So you can't display a UI that says "Installing Feature1" and then later on "Installing Feature2" because that doesn't happen. All you can know is that some list of features are being installed.
Your comment asks about finding out whether a feature installed successfully or not. This issue never comes up - there are never some features that install and others that fail. An MSI install is a transaction and it either all works or fails and rolls back and deletes changes it made so that the system is restored to its previous state.
It's not clear why the list of features is so important to display. If you use the MSI's internal UI there is a feature selection dialog where the user selects which features are to be installed; if you use the Burn UI the same thing is available, so the user can see what features have been chosen.
Inside the MSI the list of features being installed (after they've been selected) is in the ADDLOCAL property, but that's the internal name. It could be used to display a list of the features that were installed at the end, but again by definition what was chosen is installed otherwise the install would have rolled back entirely. I don't believe I've ever seen an install where the list of MSI features installed is displayed at the end - it's redundant info. It would be useful to know the scenario you have, or what problem you're trying to solve, and if you believe that you need to display a list because some might install and others might fail then there is no point, as I have said.
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.
We install an application (MSI) using MSIEXEC with the following command line option:
MsiExec.exe /x{code} /qn /liwearucmopvx+ C:\Log\UnInstall.tra
MsiExec.exe /iC:\Source\App.msi /qn TARGETDIR=C:\Install ALLUSERS=1 /liwearucmopvx+ %C:\Log\Install.tra
Most of the time this works, but sometimes the uninstall fails (not sure why yet, looking into the error). Anyways when this happens I get the following error during the re-install:
Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel
Is there a way to bypass this? Meaning to ensure that we always re-install (if it exists we can simply automatically blow it away?)
Check out the MSDN Documentation on the Upgrade Table, basically you need to set the msidbUpgradeAttributesVersionMaxInclusive bit.
You don't state what you're using to build your installer, if you're using WiX 3.5 or later you can use MajorUpgrade/#AllowSameVersionUpgrades="yes" to take care of this for you.
Note that because MSI ignores the
fourth product version field, setting
this attribute to yes also allows
downgrades when the first three
product version fields are identical.
For example, product version 1.0.0.1
will "upgrade" 1.0.0.2998 because
they're seen as the same version
(1.0.0). That could reintroduce
serious bugs so the safest choice is
to change the first three version
fields and omit this attribute to get
the default of no.
Note that instead of having to remember the package code (a real pain if you're using auto-generated package codes with Continuous Integration) the following VBScript will remove the package by name by searching the list of installed products and finding the package code itself.
Option Explicit
Dim productName, productCode, installer
productName = "My Application"
Set installer = Wscript.CreateObject("WindowsInstaller.Installer")
For Each productCode In installer.Products
If InStr(1, LCase(installer.ProductInfo(productCode, "ProductName")), LCase(productName)) Then Exit For
Next
If Not IsEmpty(productCode) Then
Dim WshShell, oExec
Set WshShell = CreateObject("WScript.Shell")
Set oExec = WshShell.Exec("msiexec /x " & productCode & " /qb /l*v ""%temp%\UninstallApp.log"" ")
End If
The question is quite older, but the existing answers are missing the essence of problem and solution while useful for other scenarios:
If the uninstall fails, you have a serious problem, and there is no better way than analyzing this- otherwise you could get in more trouble later.
At least, I would write a small script/program, which uses the return value of the uninstall or, even more powerful, tests, if the MSI is still installed- BEFORE you try to install the new MSI.
I would give more information how to do this, if there is interest in this, but there is already information on SO in other questions.
Some other answers recommand, that you should use Major Upgrades (every new build can/should be a correct Major Upgrade in this scenario, at least as a recommendation). This is a good recommendation, but does not help, if uninstalls are failing "sometimes".
Moreover it is important to state, that most often, the error you mention, shows that you are not using Major Upgrades already.
If you have really a problem with uninstalls, then a Major Upgrade could increase problems, because dependent on the configuration, it can install the product a second-time MSI-wise and you have two MSI references on this, what is still one product for you. More details would lead too far. Just remember, an (always) working uninstall or at least a test for this has to be assured before further update steps.
The script from saschabeaumont is really short and nice. What it is doing, is to assure, that you are really using the correct ProductCode. The main need is, because it has to change every time, you produce a Major Upgrade...
In your case: This solves only ONE scenario, why your uninstall could have failed...
If the uninstallation fails the product will still be registered on the system - depending on where the failure occurs the uninstallation will rollback, leaving the product still installed.
If you attempt to reinstall a product with the same product code but different version on top of an existing installation MSI will complain, rightly, that the product is still installed. If you want to achieve upgrade behaviour then you need to change the product code and write entries into the upgrade table so that MSI can discriminate between the old and new products and use the RemoveExistingProducts action to remove the old product before or after the newer version is laid down.
If you want to understand why the uninstallation failed, you need to look at the logs, typically look for 'return value 3' which is the signature of a failed installation action.
When trying to remove our application in Add/Remove Programs, the following error pops up, and the application fails to uninstall:
Error
'mFileBagIDE.dll' is not a valid short file name.
The curious thing is that you only get this error if the original installation DVD is not in the drive. If the DVD is in the drive, the uninstall works perfectly.
Here's the real kicker: we did not catch this bug until after our application was already widely deployed, and our clients' situations are such that it is likely many of them no longer have their original DVD. This means that the next version's installer (doing a windows installer major upgrade) will fail because it is unable to first remove the previous version.
So, my question is twofold:
What did we do to create this problem so we can avoid it in future releases?
Is there a way to tell our next windows installer to ignore this error and go ahead and remove the previous version?
Our current installer (the one that is causing problems) was generated using InstallAware. We're likely moving to WiX. But solutions in any platform (InstallAware, WiX, raw MSI tables) are appreciated!
UPDATE: I have the following row in both the InstallExecuteSequence and InstallUISequence tables in my MSI, which may very well be relevant, but I have no idea what the SRCDIREX property is, or where it is being set.
| Action | Condition |
|---------------|--------------|
| ResolveSource | NOT SRCDIREX |
Probably one of the actions (either standard or custom) that references the original MSI was not conditioned to run on installation only (for example, ResolveSource should be conditioned as "Not INSTALLED"). You might be able to workaround this with a patch (an MSP file) that changes the condition on the relevant action.
I would start by determining which action is causing the error. Here's how I would do that:
Install your app from the dvd
copy the msi file to some local folder, let's say "c:\temp"
Remove the dvd
kick off the uninstall like this: "msiexec /x yourapp.msi /L*v c:\temp\uninst.log"
When the error comes up, the uninstall is effectively paused. You can then check the end of the log to see exactly where you are in the sequence. That should help you to debug.
If the answer really is ResolveSource, regular patching may not be an option.
Heath Stewart mentions this in his blog -
http://blogs.msdn.com/heaths/archive/2007/10/25/resolvesource-requires-source.aspx
"In general, do not schedule ResolveSource. If this runs when installing a patch, for example, the user will have to insert the original media whether they would otherwise need to or not."
If that's the position you find yourself in, you could create a transform that updates the condition on your ResolveSource action, and apply that to the cached copy of the msi file manually. It's a bit of a pain, but I'm pretty sure that would work.
have you tried to copy those files to %WinDir%/system32 folder?
EDIT: Make a setup to copy all the setup MSI package to the disk, and install it from the diskdrive.
Remove every files uneeded to uninstaller. Adobe, HP and many other companys are doing that.