Showing results for 
Show  only  | Search instead for 
Did you mean: 
Level 2

OCX in different paths, self registering, interferes with each other

I'm creating Basic MSIs for two of my company's products. Originally it was one product and installed with WISE, now two closely-related products installed with IS2016 MSIs going in two different subdirectories. There's a particular OCX that has to be 'self-registered'. Both MSIs seem to handle that fine -- if you install one product, you get the OCX file appearing in that product's subdirectory, and it's registered.

The problem comes when you install both products on the same machine.Same OCX appears in two different paths, but still no problem -- until you try to Uninstall one of the products. It breaks the registration of the remaining product, requiring the User to either run a Repair or to run regsvr32 on the remaining OCX.

What I'm confused about is that both MSIs each have one Component that contains only the OCX file, marked as a Key file. The Components are both marked as Shared, and the files are marked for Self-Registration. IS documentation suggests that IS would create an entry in HKLM\Software\Microsoft\Windows\CurrentVersion\SharedDLLs (and increment a Reference count), but there is no such entry for either one of them.

I have two questions:
a) What's best practice for needing the same OCX with two products? I was thinking of creating a SharedComponents folder under our Company's INSTALLDIR, placing the OCX there and just not including it in the Uninstall process, but my compulsive self wonders
b) What I missing here -- shouldn't entries exist in SharedDLLs registry already?
Labels (1)
0 Kudos
(1) Reply
Level 8

You should read this article about shared components:


0 Kudos