By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,409 Members | 1,043 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,409 IT Pros & Developers. It's quick & easy.

About using Merge Modules for installing shared components

P: n/a

I have a question regarding the functionality of merge modules. Since this
relates to my previous queries, I'll just give you a brief background on the
topic. I had to make an installer for an application which was to share dlls
with another application and these dlls were not self-registering. Someone on
the forum suggested a few methods for the Visual studio installer, but since
I had been using another software, a certain 'Installer2go', I didn't get
around to trying this on vsi.

Installer2go is somewhat like vsi, but does a few things quite easily, like
setting environment variables. It essentially generates an msi file, which
can then be modified (if needed) using Orca, and that's what I was relying on
(in retrospective, might not have been the best approach)

Anyhow, initially, as a quick fix, I used the SelfReg table of orca to force
the dlls to register but I noticed some serious problems caused by this
method. If you uninstall your software, the installer seems to just delete
the GUID for the dlls from the registry without checking if they're being
used by any other applications. So essentially, if a computer has both
applications running, and one of them is uninstalled, the other will stop
working, unless the user re-registers the shared dlls using regsvr32 (for

Eventually I found what seemed a better way to counter this problem. I am
not entirely sure about this and hopefully, someone can verify this for me -
Merge modules, it seems are good for when shared components are to be used. I
made a merge module project in the Visual studio .NET IDE and added all the
shared dlls. In the properties windows of these dlls, I changed the
'Register' option to 'vsdrfCOM' and the 'SharedLegacyFile' option to 'True'.
The register option was set by default to 'vsdrfCOMSelfRef' but I was afraid
that would do the same thing as the SelfReg table so I changed this. Setting
SharedLegacyFile to true seems to keep a reference count of the dlls each
time an installer is used which has the given merge module embedded in it.
And once you uninstall the application, it looks for which all applications
are using the shared dlls, and if it's only the application being
uninstalled, then the dlls are removed from the registry, else they are

The only problem here is that any other installer, especially the one used
for the other application must use this merge module too else it will have no
way to know that the dlls are being shared. But in principle it seems to be a
better approach as it at least has some way to check for shared dlls. I'm
guessing the right thing would have been for the authors of the other
installation package to make a merge module for all such dlls and just pass
it on to anyone who'd need it for their application installers. Incidentally,
when I checked the msi file for the previous installer (using orca), I found
that they had bunched all their 'non self-registering' dlls under the SelfReg
table, which I feel they should not have done in the first place.

Oh well, I am just wondering if I'm even thinking right about this and if at
all there is any other way to approach this problem. Are merge modules used
primarily for the functionality I have pointed out or do they address another
issue more appropriately? I would be glad to hear any comments or suggestions
regarding this matter

Thanks a lot
Nov 17 '05 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.