This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Basic MSI: Major Upgrade problem with file versioning rules of Windows Installer.
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 28, 2007
01:44 AM
Basic MSI: Major Upgrade problem with file versioning rules of Windows Installer.
Hi.
We are trying to get a major upgrade to work, but there´s a problem that we are not able to understand.
Basic MSI project:
The RemoveExistingProducts Action is sequenced between 'InstallValidate' and 'InstallInitialize'. After installing the Major Upgrade some of the component key files are missing.
The log file reports (during CostFinalize):
Disallowing installation of component: {BCB1753C-38D3-40A4-9AD5-DA8F6D6F4571} since the same component with higher versioned keyfile exists
for those components (some true type fonts and DLLs). But these files are still the same. No changes were made to them. Timestamps, create and modified date and file version are all the same.
I´ve also created a simple test project using the true type font components only. Same problem occurs on a clean system using this simply test project.
For me it looks like that the file version compare in MSI is a little wacked.
Moving the RemoveExistingProducts Action after the InstallFinalize action would solve the problem but it does not change the outcome of file versioning rules of MSI.
So I really would like to know and understand what´s going wrong here.
-Nick
We are trying to get a major upgrade to work, but there´s a problem that we are not able to understand.
Basic MSI project:
The RemoveExistingProducts Action is sequenced between 'InstallValidate' and 'InstallInitialize'. After installing the Major Upgrade some of the component key files are missing.
The log file reports (during CostFinalize):
Disallowing installation of component: {BCB1753C-38D3-40A4-9AD5-DA8F6D6F4571} since the same component with higher versioned keyfile exists
for those components (some true type fonts and DLLs). But these files are still the same. No changes were made to them. Timestamps, create and modified date and file version are all the same.
I´ve also created a simple test project using the true type font components only. Same problem occurs on a clean system using this simply test project.
For me it looks like that the file version compare in MSI is a little wacked.
Moving the RemoveExistingProducts Action after the InstallFinalize action would solve the problem but it does not change the outcome of file versioning rules of MSI.
So I really would like to know and understand what´s going wrong here.
-Nick
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 29, 2007
04:39 AM
anyone? 🙂
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 04, 2007
12:47 PM
We have run into this same problem. The way we got around this problem was by by moving the RemoveExistingProducts standard Action to before the costInitialize action (we normally set ours to 790 to accomplish this).
A couple things to remember here. One, this is not a recommended practice by Microsoft. Two, if you monkey around with the Major Upgrade Settings, the RemoveExistingProducts action will be defaulted back to where it was.
You should test your install to make sure this solution works for your needs.
Microsoft's recommendations:
http://msdn2.microsoft.com/en-us/library/aa371197.aspx
Another Macrovision support thread discussing this;
http://community.installshield.com/showthread.php?t=142624
Hope this helps.
Cheers,
Bill
A couple things to remember here. One, this is not a recommended practice by Microsoft. Two, if you monkey around with the Major Upgrade Settings, the RemoveExistingProducts action will be defaulted back to where it was.
You should test your install to make sure this solution works for your needs.
Microsoft's recommendations:
http://msdn2.microsoft.com/en-us/library/aa371197.aspx
Another Macrovision support thread discussing this;
http://community.installshield.com/showthread.php?t=142624
Hope this helps.
Cheers,
Bill
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 27, 2010
08:57 AM
I have run into this as well. My major upgrade completes successfully, but there were a handful of fonts and dll's that were missing afterwards. Like Holger_G mentions, the files had not changed at all between the original and upgraded versions of the product. After looking at these files for a while, I discovered that the problematic dll's had different file version information in their fixed headers and variable headers. The fixed header contained a normal period-delimited file version (6.0.0.5138). The variable header, however, contained a comma-delimited version (6,000,0000,05138).
To me, this suggests that windows installer is using the variable file header for its version comparisons and is thrown off by the commas. Since the files in question come from a third party, I don't have the option of altering their version info. Instead of changing the standard action sequencing (which can have serious consequences), I decided to assign each of the problematic files a companion file. This way windows installer does not use the file's own version info for determining its upgrade behavior, but instead forces the file to follow the behavior of another component (one which upgrades properly).
To me, this suggests that windows installer is using the variable file header for its version comparisons and is thrown off by the commas. Since the files in question come from a third party, I don't have the option of altering their version info. Instead of changing the standard action sequencing (which can have serious consequences), I decided to assign each of the problematic files a companion file. This way windows installer does not use the file's own version info for determining its upgrade behavior, but instead forces the file to follow the behavior of another component (one which upgrades properly).