cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
KathyMorey
Level 10

DCOM server/proxy stub issue

I'm using IS12, but I believe this to be a generic issue.

We have several COM/DCOM servers in our software suite that may be installed so that several components can reside on a single machine, or each server may be installed on its own dedicated machine. We have created proxy stubs to be installed on the clients to those servers. The proxy stubs are in MMs, since they are repeated in more than one installation project, while each server is in its own installation project.

We use "Extract at Build" to capture the registration entries for both. The proxy stubs register some of the same ClassID and Interface information as the servers.

We have recently run into a situation where a customer had two servers on a machine, and decided to separate them. Uninstalling server A caused the registration entries to be removed, which means that proxy stub A on that machine (used by server B) had to be re-registered by hand before that machine would function.

We can't switch to registration-free COM because we still support older OSs that can't use it.

I realize we broke the WI component rules by allowing registry entries to belong to two separate components, but I don't know how to avoid that in this situation. Has anyone run into this problem? I would like to avoid having to manually create MMs with common registry entries in them, because we do not want to have to depend on developers to inform someone if COM entries have changed, and do not want to have to manually extract COM info for every new installation build.

I am out of other ideas and would welcome any suggestions...

Thanks!
Labels (1)
0 Kudos
(4) Replies
KathyMorey
Level 10

bump - any ideas?
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

I can't think of any great ways to handle this. The bright side is that running repair on the broken app should fix it. If I understand correctly, the root of the issue is you had a resource which was partially private, and partially shared, and reported to WI as different components each time it was installed: the server dll or exe was private to each install; its registry data was shared; and each install of it was in a component with a new GUID.

Perhaps ensuring the component has the same GUID might be enough in the future, assuming the COM data doesn't change significantly. Recent versions of InstallShield (perhaps just IS2009 and up) are much more careful about reproducing the same Registry table keys for the same Registry data, so between those two parts, it just might work out. If that's the case, just be careful about selecting the same component code in the future each time yo use this file, and perhaps write a custom ICE to check for the component code on a list of such known files, and verify the COM data is compatible (if you can come up with a definition for that).
0 Kudos
KathyMorey
Level 10

Thanks for your reply, Michael. Unfortunately, repair isn't working in this case. The key file for each component is the server exe or proxy dll, and since the file itself isn't removed, repair doesn't kick in.

Your recap isn't quite my situation: we have two components with different key files that share some registry resources. The two components are in different install projects but the two products may be installed on the same machine. Since the key files are different, we can't share a component GUID between the two, and since only some of the registry entries are shared and we use COM extract to get them, we can't easily separate the shared entries into a separate component (to put into a merge module).

I guess my question was more from the code developer viewpoint than the install developer viewpoint. Has anyone else had experience installing COM servers and client proxies where they might end up on the same machine? How do you handle the shared registry info?

Thanks.
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

So you've got two different DLLs which register various registry keys, some of which are separate and some of which are shared. From a development standpoint, the obvious theoretical solution is to separate off the overlap into a third DLL (which brings you to a state more like my previous post suggested), but I don't know how much sense this makes in practice.

Perhaps someone else has encountered this before and can comment more usefully. The lack of shared counts on registry keys themselves doesn't make this easy.
0 Kudos