Thanks for pointing out that I can cross-post messages across newsgroup.
I did not realised that I can do that.
Thanks for the prompt reply. If both my DLL are actually implemented as
Just curious. So how does the OS managed the interface registration for
well. In many cases, I also import a system defined IDL into my DLL, but
I do not see the same issue occuring.
"Angela Yan" <email@example.com> wrote in message
I have 2 different DLL files that shares a common IDL file. This
common IDL file contains some interfaces that is implemented by both
my DLL. When I register the 1st DLL file, it seems that some entries
are written into the HKCR/interface key.
When I register the 2nd DLL file, the same thing happens and the
entries are overwritten in the ProxyStubClsid32 to point to my 2nd
Are these automation interfaces marshalled via TLB, or are they custom
interfaces marshalled via proxy/stub DLL, and you are merging
proxy/stub code into the main DLL?
The problem is that you define the same interface in two different TLBs
(or provide the same marshalling code in two different DLLs - for
simplicity I'm going to assume the former for the rest of the
discussion). This is bad, for reasons you've discovered the hard way.
Take this common IDL file, and compile it into its own TLB. The two
DLLs should share this TLB file. If they don't have their own
(non-shared) interfaces, simply use MIDL-generated header or #import
the shared TLB into both projects. If they do have such interfaces,
they would need separate IDLs to describe them. In this case, don't
forget to import the shared IDL outside library section, and importlib
the shared TLB inside.
When deploying either or both DLLs, don't forget to register the TLB
too. And be careful upon uninstall - you can only remove the TLB when
all the DLLs relying on it are removed. You may need some kind of
reference counting scheme.
Can anyone advise me on what might be wrong? I not sure why is there a
ProxyStubClsid32 key created for interface for my idea of interfaces
is that it is independent of the DLL that implements it
Interface is independent of the DLL that implements it. But it depends
on the DLL or TLB that provides marshalling support for it. This is why
it's a really good idea to have exactly one such DLL or TLB, ever.
With best wishes,
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925