Re: Issue on DLL Registration
"Angela Yan" <yanyan9@hotmail.com> wrote in message
news:evzyiDsnGHA.4572@TK2MSFTNGP05.phx.gbl
Thanks for the prompt reply. If both my DLL are actually implemented
as In-proc servers, am I correct to say that I do not need to merge
the proxy/stub into my DLL since I do not need marshalling, other than
multi-threading issues?
You never have to merge proxy/stub code. You can always build a separate
proxy/stub DLL.
If you are sure your interfaces will never be used cross-apartment and
thus will never need marshalling support, mark them as [local] in the
IDL. Then no marshalling code will be generated for them, and the issue
will be moot.
However, you stated in your original post that a DLL registered as
proxy/stub for the interface does indeed get loaded into the client
process, even if it's not the one serving the COM object. This suggests
to me that you do after all use the interface across apartment
boundaries, and do require marshalling support.
Just curious. So how does the OS managed the interface registration
for the system defined IDLs or those provided by Visual Studio
Include?
What do you mean by "system defined IDLs"? What do you mean by "Visual
Studio Include"? I'm afraid I'm not familiar with these terms.
I would think that these IDLs would be considered as shared
common IDL as well. In many cases, I also import a system defined IDL
into my DLL, but I do not see the same issue occuring.
Which IDLs do you import? Don't you also have something like
importlib("stdole2.tlb")
in your IDL?
--
With best wishes,
Igor Tandetnik
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