Jump to content

This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.

Configurable merge module for COM

1 reply to this topic


  • Members
  • 2 posts

Posted 19 November 2004 - 21:59

Hi all,

I'm not sure if this is the best forum section for this question but I'll try here first.

I'm trying to build a configurable merge module using InstallShield X. This module installs some COM dlls and the user of the module is given the option of whether to register them on installation or not (if not then some manifests are installed instead for registry-free COM). The logic is carried out in a MSI dll custom action. I would prefer to use "COM extract at build" instead of self-registration since this is better practice. I have so far found two possible methods and hope someone can help me with either.

The ModuleIgnoreTable looks interesting if I can control whether the Class, ProgID and TypeLib tables get merged. Is there any way I can add or modify entries in this table before merging takes place? I can't find a way with the ModuleSubstitution table to set a value other than the configuration value itself (in my case True or False). It would be simple if the ModuleIgnoreTable instead of just listing the tables to ignore also had a option true or false...

I've found a less-than-desirable solution by creating two components for each COM dll - one which registers and one which doesn't, then using a custom action to determine which set of components to install. However the merge module is now twice the size which isn't ideal. Is there any way to use the same file in more than one component but not have it take up twice the space?

Many thanks in advance,


  • Members
  • 15 posts

Posted 24 June 2005 - 16:24

I'm not totally sure why you'd want to do this as it throws up so many issues but how about just one merge module with a Conditionalised Custom Action to run a self register on the dll.

So you'd maintain the integrity of the GUID associated with the keypath and have the option of registering the file.