I have read that i can create uninstallable MSP file. I have made the Allow Patch to be uninstalled checked while building the patch, but somehow the patch is not getting visible under Installed updates in the Program and Features screen.
Is there anything else i need to make the patch uninstallable?
The issue was because the installer was created use 'Traditional type MSI' Uninstallation of patch will only work with New Style MSI.
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 want my installer to prompt the user to uninstall an existing installation before installing the new one if an installation already exists at the selected install directory.
Right now I'm trying to just call the uninstall dialog and let it continue its normal execution from there, but since it is already in the install sequence, it continues to run functions for installing, rather than uninstalling.
Is this even possible to do? And if not, how else might I accomplish the same thing.
I'm using a Basic MSI project, and due to the nature of my installation, I don't believe I'll be able to set up a Major upgrade.
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.
I am new to WiX 3.0 and writing my first installer based on WiX (coming from Wise).
If the product is already installed (in the current version), I want the installer to switch to "repair"-mode automatically. It should behave exactly like as if I would have clicked "repair" in the Windows software dialog.
It must behave like this to fit in the overall installation process of the system.
I read the documentation but can't get hold of the problem...
You can use the Installed property to conditionalize a SetProperty element for REINSTALL and REINSTALLMODE properties. Be careful to test upgrades to ensure that you add the other parts of the condition (REMOVE<>"ALL") so that the upgrade of the old product stays an uninstall and doesn't flip to repair. :)