i have a code in MFC that is calling MsiInstallProduct(installerFullPath, commandLine);
is it possible to install 2 MSI products at the same time?
as long as they are both independent.
is it possible to call a windows function and give it ALL of my MSI components and it will install them one by one?
Windows Installer does not allow installing multiple MSI packages at same time.You need to trigger the installations one after another, waiting for the first one to finish before you launch the second one. The only option to install them in a single call is to create another MSI package, a main one, in which you add the two ones as chained packages.
Before Windows Installer 4.5, Bogdan's answer was correct. However since with Windows Installer 4.5 and later, you can perform a Multiple-Package Installation. Do this by callling MsiBeginTransaction, some combination of APIs such as MsiInstallProduct, MsiApplyPatch, or MsiConfigureProduct, and then finally MsiEndTransaction.
Technically these are still not exactly installed at the same time (and it will require calling multiple functions), but this makes them all part of one transaction. If all the participating packages are correctly authored, they will either all be installed, patched, or configured (modified or removed), or all rolled back to their starting state.
The multiple-package installation mentioned by Michael is exactly the support used by chained packages, and as he also mentioned this requires at least Windows Installer 4.5 on the target machines.
To create an MSI package in which you add the two ones as chained you can use different setup authoring tools, free and commercial, depending on the time you have available. Here is a list of tools:
http://en.wikipedia.org/wiki/List_of_installation_software
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 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.
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.
Our product has several products that customer can install created as separate installation packages (MSI).
We have a requirement to have single package for the installation that will:
Show one UI with progress
Allow user to choose which features/packages to install
Have ability to constrain one feature to another (e.g removing or adding effect other)
Support single elevation (UAC)
nice to have ability to auto update (not must)
support command line + silent installation
the package should be built out of the isolated installations (chain them)
raise error / messages for missing prerequisites
Support patches over time and major upgrades
Today we do almost all of the above using MSI with nested installations which is bad practice and we face too many issues in our solution.
i know that there are several bootstrappers out there (m$ generic bootstrapper which i think is not good, BURN is the WIX version which is not mature enough)
Do you know of other? that work and tested already ?
What is the best method to do (without unification of the MSI into a single MSI)
dotNetInstaller looks promising. I was experimenting with it to install java as a prerequisite. It comes with a GUI editor so you don't have to sort out the xml to create a project. The config file is in xml, and the InstallerLinker can be run from the command line. It could be integrated with a build server, though some msbuild tasks would be nice.
project home:
http://dotnetinstaller.codeplex.com/
tutorial:
http://www.codeproject.com/KB/install/dotNetInstaller.aspx
Create an InstallShield InstallScript package. Use the InstallScript package kick off the .MSIs with "-qn" one by one. I do this and am successful with it. I believe it meets your all the requirements you listed.
Until Wix's Burn is ready we really don't have much of a choice when it comes to bootstrappers.
If you are using InstallShield as your msi designer, one thing you could try is making an InstallScript project that contains all the different msi packages. You could then silently install only the desired packages. InstallShield is pretty expensive though, so if you don't already have it, you'll probably have to end up rolling your own bootstrapper.
I often get a problem with Windows Installer trying to uninstall a package, but it complains that:
The feature you are trying to use is on a network resource that is unavailable.
Is there a known means of uninstalling such packages when the original MSI is simply not available?
Please note that Microsoft has now released an official tool to resolve these issues, without the problems that previously existed with MSIZAP.
Microsoft Fixit: Fix problems with programs that can't be installed or uninstalled
Take a look at a tool called MSIZap released by Microsoft.
UPDATE:
MsiZap.exe has been deprecated for quite some time. Its use is unsupported on all recent versions of Windows, and it is considered a very unsafe tool to use.
I added a link to a newer Microsoft support tool designed to clean out installations, but this tool also appears deprecated at this point. I have removed the link from the comments section.
Perhaps try the tool linked to in saschabeaumont's answer below.
FYI, this post explains the root problem https://superuser.com/q/293542/245923
You can uninstall it using the product code:
msiexec.exe /x {your-product-code-guid}
You would obtain this code from the MSI itself, or whatever tool you are using to build the MSI.
Note that when you uninstall a product, it uses a cached MSI, since only the original MSI knows how to uninstall itself. When you use the product code, it uses the cached MSI from C:\WINDOWS\Installer.
Update, Stein Åsmul: There is a whole list of cleanup approaches here (recommended).
UPDATE:
This newer support tool can be tried on recent Windows versions if you have defunct MSI packages needing uninstall. This new tool appears to have been deprecated as well.
Perhaps try the tool linked to in saschabeaumont's answer.
It is not normal or standard MSI behavior to ask for the original source media - it indicates a badly designed MSI package. If you experience this with a vendor MSI it is highly recommended that you report the problem to their support team. Here is a more comprehensive explanation of the problem: Why does MSI require the original .msi file to proceed with an uninstall?
In most cases MSI packages can be uninstalled from add/remove programs from the control panel even if you don't have the original installation database for the MSI - the uninstall is run from a cached copy of the original MSI in the system folder %SystemRoot%\Windows\Installer (in some cases this cached MSI could be missing, see section 12 here for potential causes).
Earlier versions of MSI tended to trigger this problem (asking for the original installation media) more often (Office back in the day), and legacy MSI files can still cause uninstall problems that can only be solved using the msizap.exe tool (this tool is deprecated, outdated and no longer supported). This command line tool (msizap.exe) also had a GUI available (MSICUU2.exe), both tools are deprectated (try the link to the new cleanup tool listed above).
Just for the record: If you have access to the original MSI that was actually used to install the product, you can use this to run the uninstall. It must be the exact MSI that was used, and not just a similar one. There is a unique package guid assigned to each MSI file, so Windows will know if it is the right one.
Related answers:
wix - custom action dialogbox on silent uninstall of application
Uninstalling an MSI file from the command line without using msiexec
You didn't do something crazy like go to C:\Windows\Installer\ and delete the files in there did you?
One drawback of MSI files is you need the complete MSI file in order to uninstall or repair the application. Windows loves to store a copy of the MSI. It also renames the MSI file from a common name to a GUID with no table (that I can find) to map original names (example: Office2010.msi) to the new GUID so you have a PC with many GBs of wasted space that you can't delete. A machine that's not even 1 year old can easily hit 8 GB (example: mine).
There is an MSI cleanup utility from Microsoft, Windows Installer Cleanup Utility (deprecated tool, unsupported and unsafe to use - perhaps try this answer instead: Uninstall without an MSI file).
Or CCleaner can usually do this
Control Panel --> Add/Remove programs?
EDIT:
Your post mentions nothing about using add remove programs to uninstall the app, you said the "Windows Installer" (MSIEXEC - see the link below), which is not the same thing.
http://msdn.microsoft.com/en-us/library/aa367988(VS.85).aspx