Re: Using same interfaces for in-proc vs. out-proc
Drew <dam@dam.com> wrote:
"Igor Tandetnik" <itandetnik@mvps.org> wrote in message
news:uqWu%23fmXKHA.4588@TK2MSFTNGP04.phx.gbl...
Drew <dam@dam.com> wrote:
That's my point. The EXE and DLL would have different LIBIDs in their
typelib. One for the EXE one for the DLL.
Why? They describe the same interfaces with the same IIDs, right? Why
do you want different LIBIDs?
---------
So that they can both be registered at the same time.
They can't anyway, really. Registry entries under HKCR/Interface/{IID} =
can only point to one LIBID at a time.
Otherwise, how
do you distinguish between a reference to the EXE and a reference to
the DLL?
A reference from _what_ ? This question makes no sense to me.
Suppose one VBA user wants to use the EXE andd one wants to
use the DLL. How do they reference them if their LIBIDs are the same?
By CLSID, of course. LIBIDs don't participate in server activation in =
any way.
Yes. But, again, you'll have a problem if the one that was registered
last is uninstalled first, because it'll remove marshalling support
for your interfaces from the registry.
-------------
That's my concern. Having unique LIBIDs isn't enough to support the
idea that's being proposed.
In fact, it's not helpful at all.
How would the non-unique IID interfaces resolve which
server they referred to?
IIDs do not refer to a server: after all, thousands of servers
implement IUnknown or IDispatch. IIDs (often) refer to a LIBID, with
the type library providing marshalling support. Now, you are
attempting to tie a LIBID to a server: your problems stem from that.
-------------
Maybe when I referred to server I should have said LIBID that
referred to the COM server.
LIBIDs don't refer to a COM server. They just refer to a blob of data in =
a certain format. This data may be stored as a separate file =
(customarily with .tlb extension), or it may be embedded in some EXE or =
DLL, which may or may not happen to also house a COM server =
implementation: whether or not it does is completely irrelevant.
Am I mistaken that the LIBID *is* tied to
the server?
Yes, you are mistaken. That's what I'm trying to tell you for days now.
I mean from a VBA client point of view, they need to add
a reference to a server that is looked up using the LIBID, right?
No. When you add a reference at compile time, you are just pointing the =
compiler to a file. The type library doesn't even need to be registered =
for your code to compile. Once the type information is read and the code =
is compiled accordingly, the type library is no longer needed at runtime =
at all. This is similar to the situation with .h header files in C++, =
say.
At run-time, COM machinery itself uses the type library to allow COM =
calls to work across apartment (e.g. process) boundaries: this is known =
as "marshalling". That's why an interface IID needs to point to a LIBID =
in the registry. Also, ATL's IDispatchImpl happens to use a type library =
to forward late-bound IDispatch::Invoke calls to appropriate interface =
methods, and also needs the type library registered so that it can look =
it up by LIBID. Note that this is an implementation detail of your =
server, not a requirement imposed by the client.
Now, often but not always, a type library contains one or more "coclass" =
blocks mentioning specific CLSIDs. This is done mostly for the benefit =
of clients like VBA that consult type libraries during compilation: =
these CLSID references are not used at runtime in any way.
In your situation, with two coclasses sharing a set of interfaces, I can =
suggest two approaches. One is a single type library with two coclass =
blocks:
library {
[dual]
interface IMySharedInterface : IDispatch {...};
coclass MyInProcServer {
[default] interface IMySharedInterface;
};
coclass MyOutOfProcServer {
[default] interface IMySharedInterface;
};
}
The other involves three IDL files compiled into three type libraries:
// shared.idl
library {
[dual]
interface IMySharedInterface : IDispatch {...};
}
// inproc.idl
library {
importlib("shared.tlb")
coclass MyInProcServer {
[default] interface IMySharedInterface;
};
}
// outpfproc.idl
library {
importlib("shared.tlb")
coclass MyOutOfProcServer {
[default] interface IMySharedInterface;
};
}
The single type library in the first case, and the shared type library =
in the second, would be packaged as a standalone TLB file and treated as =
a shared resource for deployment purposes (that is, it should be =
installed and registered as long as at least one of your servers is =
still present on the machine). The two coclass-specific type libraries =
in the second approach could go into their corresponding servers' =
resources.
--
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