Hopefully I can explain this clearly:
I have a Visual Studio Setup Project (C++), my current build scripts do the following:
update the version numbers
update the PackageCode
update the ProductCode
This has worked without any problems in the past (approximately 20 releases).
I just did a new release where a custom action was removed (which was included in most of the previous releases). My build process was the same as above.
Now when I install I get a duplicate entry in Windows Add and Remove Programs.
ie:
previous version was 1.0.6.2 and is installed on the computer.
I then install new version 1.0.7.0 (has custom action removed)
Add and remove programs lists 1.0.6 and 1.0.7.
Any idea what I need to do to fix this? I expect what is happening is that the new version is causing the uninstaller for 1.0.6.2 to run, but is not getting it to remove the FeatureComponents that were removed as part of 1.0.7.0.
Is there a way to force their removal?
Make sure that both versions have the same installation type (per-user or per-machine). This is controlled through ALLUSERS installer property or InstalAllUsers setup project property.
Also, they should use the same UpgradeCode. You can check it in Property table by opening the MSI files with Orca.
If these conditions are met and the problem persists, try creating a verbose log and see what happens when FindRelatedProducts and RemoveExistingProducts actions are executed.
Related
My requirements are as follows:
If an application with version e.g. 12.0 is installed at C:\Folder1 and a setup with version 13.0 is to be installed in the folder C:\Folder1 then the setup of version 13.0 should uninstall 12.0 version silently and install the latest version 13.0
If an application with version e.g. 12.0 is installed at C:\Folder1 and a setup with version 13.0 is to be installed in the folder C:\Folder200 then the setup of version 13.0 should install the latest version and also retain the version 12.0
Things I have tried :
If I use the upgrade code method to uninstall the previous version then the uninstall of previous versions will happen even if the previous version is installed anywhere on the system.
Using custom action - create a vbscript to read the installed products using WindowsInstaller.Products data and using the Product code created a command to uninstall the application using "msiexec.exe /x ProductCode"
This custom action when added in the "Before File Transfer" section in install shield project, gives a pop-up that "The application is installing the version and to wait till it has completed the process".
The "Wait for Action" property for the custom action is set to Yes.
I tried setting it to "No" as well still same pop-up appears.
If I add the custom action in the section of "After setup complete Success Dialog" in install shield project, then both versions are installed and after the vbscript executes, it does uninstall the previous version.
The problem with this approach is, when I double click on the desktop icon of the application; it starts installing and displays pop-up of the progress of installation. This would be confusing for the customer.
So this approach is not suitable.
We have not added any data in registry so cannot use the registry method to uninstall previous versions.
This is a very basic requirement for any software, but I am not able to make out how to achieve this. Please let me know if anybody has some pointers.
I have Installshield limited edition 2015 and Visual Studio 2015 Professional.
This actually is not a "basic requirement for any software." The basics are if a ProductCode/UpgradeCode is installed upgrade it.
For point 2 you're getting the pop-up because you're trying to run 2 MSI ExecuteSequences at the same time. If you'd like to continue down this road you'll have to move your uninstall action to the UISequence. Beware that silent installs will not run this action since it never hits the UISequence. Also, the better way to head down this road is to build your own bootstrapper (setup.exe) that controls the flow of uninstall/install.
You can't do that because an upgrade (a major upgrade) MSI doesn't care where the previous version of the product is installed. An new MSI with an UpgradeCode (and a few other details) will upgrade an existing product that matches, uninstalling that older product wherever it's installed.
Some Issues (not a complete list):
If you want to install another product and NOT upgrade the existing product then you need an MSI that (for example) has a different UpgradeCode or doesn't do a RemoveExistingProducts.
Your MSIs (old and new) need to set ARPINSTALLLOCATION, so you can ask where they are installed. That lets you compare install locations (but IMO not an ideal solution).
There are issues such as whether the two separate installed products now have the same shortcuts in the start menu, whether there are any shared files in common locations, whether there are any non-shareable items (service names, global event names etc).
There are also maintainability issues, such as how to upgrade or patch two almost identical installed products.
Anyway, I would simply ask the user if they want to an upgrade or a side-by-side install, rather than base that decision on a choice of folder (which seems IMO an unusual side effect of choosing an install location).
The general choices are probably based on having a condition on the RemoveExistingProducts action, based on a command line property or other mechanism. Or, depending on maintainability requirements you could change the upgradecode (with a transform on the command line) so that the upgrade doesn't occur. It's not clear to me that detecting the install location of the previous MSI in the browse folder dialog of the new install is straightforward.
I am afraid MSI does not lend itself too well to this sort of scenario - as you have discovered.
Is this a corporate software, or is it for general, large-scale distribution?
What is the purpose of this multi-instancse approach? Does this MSI effectively install two different versions of the same application?
Instance Transforms: I suppose you could investigate the instance transforms concept. It is intended to allow multiple installations, but I dislike the concept and have never used it actively. I am hence not able to give you the inside story of limitations and gotchas - sorry - maybe someone else can illuminate?
As PhilDW states you can use another upgrade code for the newest MSI, and then install side-by-side with the old installation. Beyond what has already been mentioned you would also need to change all component GUIDs for the new package. WiX allows component GUIDs to be auto-generated based on destination path, but not so for Installshield. The instance transform should be possible to use to install side-by-side without changing all component GUIDs - I believe.
App-V: If you are in a corporate setting, and if I had enough experience, I would also recommend that you check out App-V packaging (virtualization). This allows isolation of applications so multiple versions can run side-by-side. But again, I am not the right guy to give you the inside story. I know there are a number of limitations, but can't elaborate with real-world experience.
Setup.exe Launcher: If your application gracefully handles multiple instances without clashing shortcuts and service name etc... (like Phil describes), then you could install all new versions side-by-side and never uninstall older versions by default via the upgrade table. You could then handle the uninstall of previous versions manually in your setup.exe launcher (if any). I suppose you could use the instance transform concept to install new versions, or you could re-create your setup for each new version with all new component GUIDs and product, package and upgrade GUIDs.
Legacy Installscript Project: I suppose you could abandon MSI and use a legacy Installscript project to deploy your application. I would not recommend this since such projects are problematic for reliable remote management and silent running (both for install and uninstall).
Some links for safekeeping:
WiX - Doing a major upgrade on a multi instance install
I want to install an MSI twice
Disable repair mode and upgrades in wix installer
I have a Visual Studio 2010 Setup Project and I am trying to create an Upgrade to a new version of my software.
The upgrade process is running. I properly updated the Version Number, which caused an update of the Product Code. RemovePreviousVersions is also True.
My problem is that when I upgrade my software, there is one file that may have changed on the local filesystem, in the course of running the software. I'm finding that, because the file changed, the installer refuses to overwrite it.
I want my installer to force this file to be overwritten with the new version.
Is there something I can do -- within Visual Studio, with Orca, or otherwise -- to force a file to be overwritten even if it has changed?
UPDATE: In Orca, I noticed that the "File" table includes a "FileSize" column. I believe this might be the reason the file is being ignored. If the size of the file has changed, it doesn't match. Is there any way to override this?
You can't safely change the Windows Installer replace rules, but you are getting into this situation because the upgrade mechanism first installs the upgrade on top of the older product (invoking file replacement rules) then uninstalls the old product, ref counting down and removing the product. It's the "on top" that is the issue. If you move RemoveExistingProducts in the InstallExecuteSequence from just before InstallFinalize to just after InstallInitialize you will get a complete uninstall of the older product then the install of the new upgrade. That may not work if you are expecting to keep data files around.
Otherwise you could use the RemoveFile table with Orca. You'd add an entry targeting the Component name corresponding to the file (look in the File table, and there may already be some entries in the RemoveFile table as examples). You'd set the value to be Remove on Install. The RemoveFiles action occurs before the new files are installed, so it should work.
I want to reinstall over an existing installation. is it possilble to configure MSI to automatically uninstall the existing (whatever version) and then install the 'new' version.I would like to be able to uninstall before the install and I can't seem to find out how. Any/all help would be greatly appreciated.
I have done all these steps below and still feel that the product is not getting uninstalled but instead the files are getting overwritten.
Set Remove Previous Installation as True
Set Detect new version as True
You should change version of your installer to one higher version
and it will ask you to change product code, select YES. Do not
change your upgrade code, let it be same.
Yes, you want a Major Upgrade with the RemoveExistingProducts action scheduled before the InstallInitialize action. That will cause the old package to be removed before the new one starts to install (you'll still go through the new MSI UI).
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.
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.