Old DLL Reappears, Again and Again...
I have a bit of an odd situation here. There is a dll as part of my msi installer and something about it is breaking the version checking. This dll is used to put an entry into the windows explorer context menu. Lets call this dll "Context.dll". The old file version is 5.0.0 and new version is 5.0.1. When I install onto a virgin system 5.0.1 is installed GREAT![:D] But when I install onto a system with 5.0.0 on it, 5.0.1 does not get put on[:(]. Okay, I say to myself, the version checking must be failing for some reason. I have invesitigated all the usual suspects, file version number, date, size etc. All seem to be setup for the msi installer to see 5.0.1 needs to go onto the system. Here is where it gets weird: if I have a system where Context.dll v5.0.0 is installed and I uninstall, reboot and then install v5.0.1, Context.dll v5.0.0 reappears![:@] Where the heck is it coming from? I can only speculate it is cached somewhere and is being put into the target directory in place of v5.0.1.
My questions:
1.) Where would this old version be cached at?
2.) Why would Windows installer pull out an old version of a dll and put it in place of the one in my installation package?
3.) How do I get the right version to install?
Thanks
My questions:
1.) Where would this old version be cached at?
2.) Why would Windows installer pull out an old version of a dll and put it in place of the one in my installation package?
3.) How do I get the right version to install?
Thanks
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
Inabus
16 years ago
Posted by:
StegIDM
16 years ago
Posted by:
nheim
16 years ago
Hi StegIDM,
did you log the upgrade?
If no, please do so.
Have a look at the "MigrateFeatureStates" action.
Then post the logfile on a ftp server like senduit.
Mostlikely, it's incorrect version information. This seems to be the new sport of vendors like Cisco, Apple and lot of others.
On the fast you can try this: Go to the "InstallExecuteSequence" table and move the RemoveExistingProducts action in front of "CostInitialize". Or remove the "msidbUpgradeAttributesMigrateFeatures" bit (reduce the value by 1) from the Attributes column in the upgrade table. This changes would both disable the MigrateFeatureStates action and remove the old installation completely.
Hope this helps.
Regards, Nick
did you log the upgrade?
If no, please do so.
Have a look at the "MigrateFeatureStates" action.
Then post the logfile on a ftp server like senduit.
Mostlikely, it's incorrect version information. This seems to be the new sport of vendors like Cisco, Apple and lot of others.
On the fast you can try this: Go to the "InstallExecuteSequence" table and move the RemoveExistingProducts action in front of "CostInitialize". Or remove the "msidbUpgradeAttributesMigrateFeatures" bit (reduce the value by 1) from the Attributes column in the upgrade table. This changes would both disable the MigrateFeatureStates action and remove the old installation completely.
Hope this helps.
Regards, Nick
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.