This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- OCX in different paths, self registering, interferes with each other
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Apr 19, 2018
01:52 PM
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?
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?
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Apr 20, 2018
10:22 AM
You should read this article about shared components:
https://blogs.msdn.microsoft.com/heaths/2009/12/21/about-shared-components/
regards
Markus
https://blogs.msdn.microsoft.com/heaths/2009/12/21/about-shared-components/
regards
Markus
![](/skins/images/D60DF682EA37BF37032955CE10F3F0BB/responsive_peak/images/icon_anonymous_message.png)