Assume 1 Merge Module(MSM) file which has 100 components , is added as a feature in 2 MSI applications.
1 MSI installs the MSM component on installation as one of its feature. In 2nd MSI , there is condition set so that the install level of feature having the MSM is set to "0" , which means the MSM component is not installed again through 2nd MSI. Now Both MSI are installed in the system .
Issue is when I uninstall 1st MSI , all the MSM components are removed . How to keep the Merge module components so that its usable by remaining client i.e., 2nd MSI ?
Even though 2nd MSI , didnt install these component due to condition , those components should not be removed by the 1st MSI.
Remove the Feature Condition so both Features reference track the required Components properly.
The Windows Installer will then remove the Components only when both Features are uninstalled
Related
There are 2 different product MSI. Both the MSI have different Product Code and Upgrade Code.
When 1 MSI is installed, I need the second MSI to install as a Major upgrade .
So I made the upgrade code of both the MSI same . Also In the "Upgrades" View in Installshield I have added the check to detect the same upgrade code . But it is not working . The log says "No related product found". Is it possible to make 2 different product MSI to work as major upgrade ?
If you want two different product's MSIs then keep ProductCode and UpgradeCode different. This should be standard practice.
In order for 2nd MSI to upgrade from 1st MSI, change the major upgrade setting to "Products having another upgrade Code" in 2nd one and add the UpgradeCode of 1st MSI here. This should be enough to cater your scenario.
I have 2 Inno Setup installation packages. A is dependent upon one or more components in B. Normally, A would silently install B flagging just the components it needs installed. Suppose B is already installed with user selected components. Now A will be installed and needs its usual components from package B. How to ensure this? Can I just run the silent install as usual to only additionally install the needed components if they were not already? Will this remove already installed components if they are not selected?
You can just run the install silently with the required components.
Inno itself doesn't remove unselected components but the script can perform operations to remove features when a component is not selected.
If you have control over setup B and you've not done this then you don't need to worry.
I have a .msi file created by a program called MSICREATE and doctored using orca as follows...
InstallExecuteSequence Table
* added FindRelatedProducts with sequence 410
* added RemoveExistingProducts with sequence 1450
InstallUISequence Table
* added FindRelatedProducts with sequence 200
PropertyTable
* added RemovePreviousVersions TRUE
* added SECURECUSTOMPROPERTIES SOLARUPGRADE
* had a existing UpgradeCode with guid created by MSICREATE
* had a existing ProductVersion 12.2.12.0 created my MSICREATE
Added a Upgrade Table
* UpgradeCode same value as Upgrade in Property Table
* VersionMin null
* VersionMax 99.12.31
* Attributes 1
* ActionProperty SOLARUPGRADE (same value as SECURECUSTOMPROPERTIES in Property Table)
I also assigned a new PackageCode and a new ProductCode so the new msi had different values of PackageCode, ProductCode, and ProductVersion than the previously installed product.
When I run this msi with the product previously installed, the old product is deleted, a new program files directory created and all the files except the .exe reinstalled from the new .msi. A repair will cause the .exe to be created. If the new msi is installed AFTER removing the old product (using control panel add/remove programs), all files including the .exe are installed.
The msiexec log file is mywebspace.wisc.edu/mdorl/msilog/log3.log
The .msi is mywebspace.wisc.edu/mdorl/msilog/sbl_Major_Upgrade.msi
The only things that looks weird to me are the following lines from the log. The first, second, and fourth are files that do get installed, the third is the .exe file that does not get installed. NOTE THE NULL ACTION ON THIS ENTRY.
Action start 8:04:41: InstallValidate.
MSI (s) (18:F4) [08:04:41:671]: Feature: _MainFeature; Installed: Absent; Request: Local; Action: Local
MSI (s) (18:F4) [08:04:41:671]: Component: _24A30964F6B6462282E161248AF15827; Installed: Absent; Request: Local; Action: Local
MSI (s) (18:F4) [08:04:41:671]: Component: _7B95B32E33EB4F699B44D53CA5BC22B5; Installed: Absent; Request: Local; Action: Local
MSI (s) (18:F4) [08:04:41:671]: Component: _2FBD153583AF40C09EB9920149F7C7B7; Installed: Absent; Request: Local; Action: Null
MSI (s) (18:F4) [08:04:41:671]: Component: _38A400D7DB76479CA0EC6D643D5793CD; Installed: Absent; Request: Local; Action: Local
If you look in the log at the line 603 you will find the following:
MSI (s) (18:10) [08:04:41:827]: Disallowing uninstallation of component: {ADC6C3E9-A0CF-4AFC-9998-7B9449C8EA10} since another client exists
MSI (s) (18:10) [08:04:41:827]: Disallowing uninstallation of component: {F74907E7-607E-49D1-B613-D63A36ADB020} since another client exists
MSI (s) (18:10) [08:04:41:827]: Disallowing uninstallation of component: {B1FE4023-E176-42BC-92C3-15B8E50CFBB0} since another client exists
MSI (s) (18:10) [08:04:41:827]: Disallowing uninstallation of component: {E6F5DF5D-3460-4B44-8743-48787E68A2C1} since another client exists
This can happen if the same components are shared between multiple packages installed on the same machine. Windows Installer keeps a refcount for the components and does allow removing them until all the applications that use them are removed.
If you encounter this on your test/development machine I recommend testing on a clean VM, to ensure no other previous tests affect this one.
Also, if you know you have used the same components in packages for other applications please edit them, making sure each component has an unique GUID for each package.
A keyfile is used by Windows Installer to detect the component, along with its GUID, here are more details:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa370561(v=vs.85).aspx
As you suspected, Windows Installer is also checking the file version, which I assumed you correctly incremented in the new version. Here are the rules followed by it:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368599(v=vs.85).aspx
You need to have the version column from the File table for the EXE set to a higher value then of the one already existent on the machine, otherwise Windows Installer will decide its better to keep the old one, because it has a higher version.
For the sake of putting some closure to this item, here's what I've discovered and what I did to fix things.
1) I'm still fuzzy on the meaning of versioned/unversioned file. I guess all .exe files ar versioned. I suppose this means that such files need corresponding versions in the File table.
2) I now understand the file table version need have no connection to the ProductVersion.
3) I have been using illegal ProductVersion Eg. 2012.02.16. I switched to using something like 12.2.16.
4) I set the .exe VS_VERSION_INFO FILEVERSION in Visual Studio and added the same value to File table Version field.
Now, all files are replaced when I do a major upgrade.
The entries in the file table ALL have no version. Why are the non .exe files treated differently and reinstalled?
I suppose the other files have their version increased. Windows Installer should apply the versioning rules on all the files from the package.
So this means it's impossible for a user to install an older version of a product using a major upgrade msi?
I don't see a solution if you want to keep the version smaller in the new package. Except of course, custom actions.
And what constitutes a legal version? In one place I see 255.255.65535 and in another I see 65535.65535.65535.65535
Both of them are correct version numbers. The latter value is usually set to a file to make sure it replaces any other existing file from the machine, i.e. its the highest version number allowed by the OS.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368596(v=vs.85).aspx
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
I currently have a windows product with a bootstrapper that runs 5-6 MSIs during installation. A couple of those MSIs can be upgraded out-of-band by running newer versions of those MSIs directly on the system. The bootstrapper is currently used to manage uninstalling all MSIs when the main product is removed. Is there a way to remove the bootstrapper from the uninstall logic? I'd like to find a way for an uninstall of the main product MSI to handle the removal of all the other 'children' MSIs.
For example: I have a product installer Foo.exe that runs A.msi, B.msi and C.msi during an installation. During the lifetime of the application the user upgrades B.msi to B'.msi and C.msi to C'.msi, now the user has A.msi, B'.msi, and C'.msi installed (Only A.msi shows up in ARP). How can I get the uninstall of A.msi to remove B'.msi and C'.msi as well?
You should be able to uninstall the old products by authoring a major upgrade using the Upgrade table. Maybe check out http://www.appdeploy.com/tips/detail.asp?id=106 and http://msdn.microsoft.com/en-us/library/windows/desktop/aa372374(v=vs.85).aspx .
One possible way is to have A.msi install an Uninstaller.msi. The Uninstaller.msi is basically an empty msi with Upgrade table entries for the upgrade codes for A.msi, B.msi, and C.msi. The Uninstaller.msi also has the PublishProduct standard action condition set to '0' so that it will never run. Then, A.msi manually hooks up the Uninstaller.msi to the product A ARP entry. When the Uninstaller.msi is run it executes FindRelatedProducts, RemoveExistingProducts (removing all 3 msis), and finishes without registering itself as 'installed' by windows. This gets the job done in a single, rollback-able transaction. The only trick is figuring out how to get Uninstaller.msi off the system when all is said and done...