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
- :
- Re: DCOM server/proxy stub issue
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
‎Sep 10, 2008
11:02 AM
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!
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!
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 15, 2008
08:35 AM
bump - any ideas?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 15, 2008
11:04 AM
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).
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).
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 16, 2008
07:48 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 16, 2008
10:22 AM
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.
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.