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: Installation breaks File Versioning rules
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
‎Mar 31, 2013
08:02 AM
Installation breaks File Versioning rules
Have an installation with the standard mscomctl merge module but it always overwrites the existing mscomctl.ocx. This is causing problems for our developers that need the newer version of mscomctl.ocx. new version:6.1.98.34 old version: 6.1.97.82
I need to explain to the application owners and developers why this is happening.
The file versioning rules should be in effect and not overwrite the file.
I need to explain to the application owners and developers why this is happening.
The file versioning rules should be in effect and not overwrite the file.
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 31, 2013
05:30 PM
I'm not understanding. What version is installed before and after the installation? What is your expected result?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 01, 2013
07:36 AM
Version installed before installation: 6.1.98.34
Version installed with installation: 6.1.97.82
The newer file should not be downgraded by the installation.
Version installed with installation: 6.1.97.82
The newer file should not be downgraded by the installation.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 01, 2013
08:16 AM
I assume this is a Windows Installer based project type?
Do you have a logfile? What is the REINSTALLMODE property value? Is this DLL the keyfile of it's own component? Does it have a version override value in the File table?
MSI has been around for nearly 15 years. It behaves in very predictable ways.
Do you have a logfile? What is the REINSTALLMODE property value? Is this DLL the keyfile of it's own component? Does it have a version override value in the File table?
MSI has been around for nearly 15 years. It behaves in very predictable ways.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 01, 2013
08:49 AM
This is the standard mscomctl.ocx Windows Common Controls ActiveX Control DLL merge module version 6.1.97.82.
The installation is not an upgrade.
File Versioning Rules state: Highest Version Wins—All other things being equal, the file with the highest version wins, even if the file on the computer has the highest version.
This is not the case as the newer version is being overwritten with the older version.
The installation is not an upgrade.
File Versioning Rules state: Highest Version Wins—All other things being equal, the file with the highest version wins, even if the file on the computer has the highest version.
This is not the case as the newer version is being overwritten with the older version.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 01, 2013
09:06 AM
You are over simplying the file versioning rules. It's not really relevant that the install is an upgrade.
The rule you cite assumes:
1) That REINSTALLMODE=omus ( I asked what it was, you didn't answer.)
2) That the file in question is the keyfile of a component.
3) That "version lying" hasn't been utilized. (aka "Always Overwrite")
Can you post an installer log?
The rule you cite assumes:
1) That REINSTALLMODE=omus ( I asked what it was, you didn't answer.)
2) That the file in question is the keyfile of a component.
3) That "version lying" hasn't been utilized. (aka "Always Overwrite")
Can you post an installer log?
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)