DLLs and Versions

[CChong]

We recently received 3 new DLLs from a vendor that are supposed to fix a problem we reported. The DLLs do fix the problem but the vendor kept the version the same as the previous 3 DLLs (we're trying to get them to change the version).

So, when we packaged the app (for the purpose of this thread App A), we used the override system version and bumped up the version in the MSI for the 3 DLL.

We have a product (for the purpose of this thread, App B) already out to all of our users that contains the 3 older DLLs. We now have to deploy App A, which is not a replace to App B.

The problem we are finding is that whenever someone repairs App B, it replaces the new DLLs with the older ones. I assume this is because the versions are the same.

What is the best way to resolve this situation? Merge module?

Thanks!

[DavidLock]

I believe you need to look at the component codes. If you are writing the same dll to the same folder then the component codes should be synchronised. That means either creating your own merge module, or just manually synching those component codes.

You will then have an entry in the registry;
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData
plus the SID of the user who installed the app, with a components key followed by the packed GUID of each component installed on the machine. So you will have one reference to the component which points to the highest version of the dll. Even if you then uninstall application B, which installed the higher version dll, the dll will remain because we have our reference in the registry telling us that application a needs it. The higher version will remain so it would need to be backwards compatible.

One problem is that if our dll is uninstalled by accident, and we then launch an advertised shortcut to application a, then the original lower version dll will replace the deleted higher one. This might mean that application B doesn't work anymore. To resolve this we could force a repair from add/remove programs for application B. This would replace the higher version dll.

[CChong]

DavidLock, thanks for the reply.

We did synch the GUIDs on these. And you're right, when you uninstall App B (or A for that matter) the DLLs remain. The problem is that when you re-install App B, it replaces the DLLs. Note that the new and old DLLs have the same exact version -- the vendor never changed the version. The date/time stamp is different but the MSI seems to not check the date/time stamp.

The reason this is important is because our Helpdesk does a lot of uninstalls/re-installs in order to correct problems that occur.

And, yes, if you then verify App A, it does correct it but I'm hoping to be able to avoid that altogether.

We also consider making the DLLs permanent but that does not seem to be a good idea since these DLLs are likely to be upgraded in the future. So, the only other option that we're considering is simply isolating these DLLs.

Thoughts?

[looeee]

you could always hack a new version number into the file

http://www.heaventools.com/

looeee

[CChong]

I originally searched all over for something like this tool -- this is awesome!

I downloaded the product and it goes well beyond just the ability to change the version. It is an incredible tool!!

Thank you!