New files not installed for Major Upgrade
We are working on a Major Upgrade for our product, and are having issues installing the new versioned files. Our verbose log contains many messages like this:
MSI (c) (CC:0C) [13:44:35:397]: Disallowing installation of component: {D5C883A0-FED6-4CC1-8FB8-E30E1865F960} since the same component with higher versioned keyfile exists
We have sequenced RemoveExistingProducts immediately after InstallInitialize and have been able to determine that the old product is uninstalled before it installs the new, but all of those "Disallowing installation of component" messages are coming during CostFinalize (before RemoveExistingProducts). The new un-versioned files are installed with no problem.
We have a strong suspicion that this is due to our changing of the file versioning structure for our Major Upgrade, which we figured we could do since the Major Upgrade uninstalls the old version before installing the new. Here is a sample of our file versions:
Old (product to be removed): 93.1500.00.00
New (product to be installed): 93.01.00.1000
So our old product had our build numbers in the second digit, but we'd like to use the second digit as a "minor version" for our new product files and place the build number in the last digit.
Since 01 < 1500, I believe this is the cause for all the "Disallowing installation of component" messages, but I am wondering if there is a way we can get around this while keeping the file versions as we want them for the new product.
Comments
In case it helps, I have attached our log.
So, we found a workaround - which we are not sure if its correct. We included a condition in our msi script
If((Not Installed) AND (OLDPRODUCT <> NULL))
Set REINSTALLMODE = amus
End
where OLDPRODUCT is the ActionProperty in the "upgrade" table. Setting the reinstallmode to amus seems to install all the files with the correct version. Do you think we could have any issues in the future patching this?
Thanks.
Make sure you test it in all cases: install/modify/remove/upgrade. I don't see any unforeseen problems...
Thanks for the response Bill. Could there be any other way to do this other than forcing REINSTALLMODE or changing our file versions to adhere to the Windows Installer guidelines?
Well, changing the file versions would be the place to start. There are rules that must be followed, and a failure to do so will generally cause you problems down the road. Most companies use major.minor.rev.build and it seems to work for them.
But in a case of major upgrade, when the old product is uninstalled and wiped out from the machine itself, why should its File version be taken into consideration? I would imagine it should work like an uninstall of a product and then a fresh install of an older version of that product.
This looks like a bug in the windows installer.
That depends on where your RemoveExistingProducts action is sequenced. Check the SDK on the 4 common placements and the effects they have. If it is late in the sequence then your new files are already installed before the older product is removed. The new files won't overwrite the old files due to the version glitch. Then the old files are removed leaving you with a dog's breakfast of files & versions.
From looking at the log, it looks like CostFinalize determines which components should be installed, which is where the "Disallowing installation of component" messages appear. At this point, the "newer/higher" version is still on the system. Therefore those components will not be marked for installation. However they will be removed during RemoveExistingProducts.
I don't think moving RemoveExistingProducts before CostFinalize is valid solution as the SDK states RemoveExistingProducts must be sequenced after InstallValidate, which in turn should be sequenced after CostFinalize. In this case the RemoveExistingProducts is sequenced after InstallInitialize.
We have checked the 4 placement options (in Phil Wilson's Definitive Guide book), and the only 2 options that remove old before installing new are between InstallValidate and InstallInitialize, or right after InstallInitialize. After InstallInitialize seemed the best case for us as failure during uninstall of old or install of new would rollback to leave old still installed on the machine.
The other 2 options install new before removing old. We didn't try this, but logically it seems we would run into the exact same issue with regards to versioning. As pjaiswal mentioned, our problem is that the components are being "marked" during CostFinalize, but it doesn't seem we can sequence RemoveExistingProducts before this.
And again it's only our versioned files that are causing us issues. Otherwise, having RemoveExistingProducts sequenced after InstallInitialize uninstalls old, and installs new unversioned files just fine.
Do what works for you and test, test, test.
Thanks for your guidance Bill.
Mike, did you go with moving
Mike, did you go with moving the RemoveExistingProducts in the sequence table? and if so where did you place it to get this working?
We are having the same issue, but our issue is basically with our shared apps. We have our main app install into it's own folder, that is not shared, but we also have shared merge modules that go into a shared locations.
We have mainly the main product folder sorted out so that each newer version contains all the files with newer versions, but the shared components are what is now causing the issue.
What we are doing is we have standalone install project files as well as Suite install projects. The sutie installs contain the same apps that are in the standalone projects so we make it so that the Suite projects will always perform a major upgrade over the standalone installed products. This works fine as along as all the shared merge module components are newer than what is on the machine, but we have ran into a issue where if a new version of one of the standalone products is installed and then you install an older version of our Suite product that it will correctly uninstall the standalone product, but since some of the shared components had higher versions it would mark these components as not to be installed and therefore at the end of the install all shared components that contained the new versions would be missing.
So if there is a location in the sequence table that we could place the RemoveExistingProducts get this solved that would be great. So if you have done this or know where it can be placed as to not affect any other aspects of the install then could you let me know?
Thank, Tim.
Yikes
I have read the following paragraph several time but cannot make sense of it. So I repeat it here with questions:
What we are doing is we have standalone install project files as well as Suite install projects. The suite installs contain the same apps that are in the standalone projects so we make it so that the Suite projects will always perform a major upgrade over the standalone installed products.
<OK so far>
This works fine as along as all the shared merge module components <In the suite or the standalone product?>
are newer than what is on the machine, but we have ran into a issue where if a new version of one of the standalone products is installed and then you install an older version of our Suite product that it will correctly uninstall the standalone product, <Are you saying that the issue is that the older version does not correctly uninstall the standalone product, or that it does, but other things are not correct?>
but since some of the shared components <on the machine or in the standalone version or in the suite?>
had higher versions it would mark these components as not to be installed <do you mean uninstalled ??>
and therefore at the end of the install all shared components that contained the new versions would be missing. <if the shared components on the machine are newer, then why does it matter if the older shared components are not installed?>
Finally, have you looked at a verbose log of the install to see what is going on in detail?
As to positions for RemoveExistingProducts, the help file MSI.CHM has the different possibilities and their consequences documented in some detail.
You could work your way through the options, check the verbose logs, and find the best one for your requirements by a process of elimination.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
10 weeks later, I have a
10 weeks later, I have a follow-up question for Mike B, if you're stil around.
Curious as to how you officially resolved this problem (if you have that is).
I started coming across this exact same issue a couple weeks back and it's been driving me a little nuts as it does not consistently occur. I thought I had resequenced things properly last week and the problem stopped occuring.
But today, we did two builds (v9.5.20.1 and 9.5.20.2, for what it's worth)...same build script that was fixed a week back and has been built daily since. However, upgrading from the .1 to the .2 installer results in 7 key components generating the "Disallowing installation of component since the same component with higher versioned keyfile exists" message...eventhough these files have version numbers higher than what's already on the system.
The install also has RemoveExistingProducts sequenced to occur immedately after InstallValidate
Thanks for any feedback
-d
Do you have one file per component?
Note that the log message states "Disallowing installation of component since the same component with higher versioned KEYFILE exists"
If you are not using the rule of having one file per component, then it is perfectly possible that the KEYFILE used in the original component is newer than the KEYFILE of the upgrade component holding other, newer, files.
Also note that windows installer does not check the fourth field of the Product Version property :
(From MSI.CHM)
ProductVersion Property
The value of the ProductVersion property is the version of the product in string format. This property is REQUIRED.
The format of the string is as follows:
major.minor.build
The first field is the major version and has a maximum value of 255. The second field is the minor version and has a maximum value of 255. The third field is called the build version or the update version and has a maximum value of 65,535.
Remarks
At least one of the three fields of ProductVersion must change for an upgrade using the Upgrade table. Any update that changes only the package code, but leaves ProductVersion and ProductCode unchanged is called a small update. The three versions fields are provided primarily for convenience. For example, if you want to change ProductVersion, but don't want to change either the major or minor versions, you can change the build version.
Note that Windows Installer uses only the first three fields of the product version. If you include a fourth field in your product version, the installer ignores the fourth field.
Therefore your upgrade is technically flawed in that your first three fields are identical.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
Problem resolved
Install was using one file per component. Problem occured in installs versioned at 9.6.9 and 9.6.10 as well.
Found the 'fix' however....build was done through an automated routine. WSI was being compiled via a commandline execution of wfwi.exe
Changing the routine so that it actually fired up the WSI in the Wise GUI and manually compiling from there, solved the problem, with no other changes to the WSI.
Since there have been follow-up questions to this
I marked one of my posts as the solution that ultimately worked for us. We sequenced RemoveExistingProducts immediately after InstallInitialize, but the checking is done during CostFinalize to determine if a component should be installed based on the versioning rules, and it's not possible to sequence RemoveExistingProducts before CostFinalize.
So what we had to do was put in a condition to set REINSTALLMODE to amus to force the files to be installed. It's not a pretty solution, but we backed ourselves into a corner where ultimately this was our only option.
Would you like to reply?
Login or Register to post your comment.