2 replies to this topic

[keith]

I have 2 different applications, App1, which was written some time ago, includes an OCX (a vb activex dll) which we also wrote. Now we have written a second application, App2,  which I am currently creating the install for. The OCX is also included in App2, although the OCX was changed slightly. The OCX is completely backward compatible.

Everthing works fine if I install App1, then install App2. But if I install App2 first, then App1, the OCX is overwritten with the older version included with App1. Both installation programs are written using Visual Studio Installer v1.2.

The version number (as reported by windows explorer) for the OCX included in App1 is 3.0.0.32. The OCX included in App2 has a version number of 3.1.0.0. The file date/time for the OCX included in App1 is earlier than the OCX included in App2.

I have tried the following to see if it makes a difference:

Originally, the ComponentID as seen in VSI for the OCX was different between the 2 installs. I changed the ComponentID in App2 install to match the ComponentID of App1's install, but the problem still occurred.

I created a Merge Module (using VSI) for the OCX and used that in App2 install but it made no difference.

After each of the test installs, I checked the OCX file and it existed twice, once in the install directory for App1 and once in the install directory for app2. Each had the correct file version number and date.

I looked in the Registry under hkey_local_machine/software/classes/myocxname and got the clsid

Then I looked in the Registry under hkey_local_machine/software/CLSID/Guid for my OCX and the InProcServer value had the path for App1 (the older application). Prior to installing App1, the path was the path for App2. So it appears that when I install the App1 AFTER app2, the installer updates the path to the OCX to the older version of the OCX.

Can somebody help me figure out what to check/change next?

Thank you

[hteichert]

First of all:
You don't install a shared OCX. Shared means that the same DLL/OCX/whatever is used by all apps using the functions of this DLL/OCX/..
The OCXs you are installing are installed to the path ...\App1 and ...\App2 and due to these different locations - depending on your App - you have two different files installed. They use the same regkeys in HKLM/SOFTWARE/Classes/.., but are in different locations. During the installation process the installer cannot do a version check and only install a newer version, because in the destination directory there is no OCX already installed. The version check doesn't work via Registry, it's directly working via the file version info.

So, what can be done?
For future projects it's a good idea to install shared components to always the same installation folder. In former times the "windows\system" folder was used very often, but today it's better to use a subfolder on "program files\common files" like "program files\common files\My Company Shared". Microsoft began doing this with ADO, Office components, etc. and a lot of other companies are using this structure, too. But this will only help for new files, not for your current problem.

I think there is only one way out of this, because your old installer is already delivered and it's not aware of possibly in another place installed newer versions of your OCX - but I don't think you and the other developers in your company like it:
It's necessary to create new classes in the source of your OCX and let your new App2 only use these new classes - the whole App2 would have to be changed. That way it's possible to go the "common files" way for further new apps without having installations of your old App1 destroy the registry bindings to your new OCX.
It's not a problem to create a setup for a new App which is aware of the elder versions - it's a problem to create a setup which is aware of what the future will bring. Your problem arises from your old installer - you cannot change it anymore, it will always overwrite the HKLM/SOFTWARE/Classes entries as soon as it is installed to another folder than an already installed newer version of your OCX.

Sorry for this, but I can tell you that you're not alone. Even the "almighty" MS had this problem several times.

[keith]

Thanks for the help. Every thing you said makes sense, I should have realized that myself. Luckily, there is only one public function in that ocx so the changes to app2 won't be very difficult.

I appreciate the help!