/build/static/layout/Breadcrumb_cap_w.png

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

0 Comments   [ + ] Show comments

Answers (4)

Posted by: Inabus 16 years ago
Second Degree Green Belt
0
If the file is being installed to the System32 folder it will be having the Permanent flag set, this could be the cause of the problem if that is the case.

P
Posted by: AngelD 16 years ago
Red Belt
0
Is the DLL cached in the "C:\WINDOWS\system32\dllcache" folder?
Posted by: StegIDM 16 years ago
Senior Yellow Belt
0
Installed to system32? No it is installed to the default installation directory under program files.

Also, I am seeing this on a Vista system. As I understand it they do not use the old dllcache folder but a new system under Vista.
Posted by: nheim 16 years ago
10th Degree Black Belt
0
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
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ