Re: Using same interfaces for in-proc vs. out-proc
"Igor Tandetnik" <itandetnik@mvps.org> wrote in message
news:eGkyrl7YKHA.2160@TK2MSFTNGP02.phx.gbl...
Drew <dam@dam.com> wrote:
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;
};
}
--------------
It seems that in this case, there can only be one COM server
registered at a time
What makes you think so?
---------------
One typelib - one registered COM server.
---------------
and that neither is prevented from using either
of the coclasses (MyInProcServer, MyOutOfProcServer).
I don't understand what you mean by "using a coclass".
---------------
VBA:
Dim MyInproc as MyLibrary.MyInProcServer
Dim MyOutproc as MyLibrary.MyOutProcServer
Set MyInproc = new MyLibrary.MyInProcServer ' What is invoked in this case,
EXE or DLL? My guess is whichever was registered last.
Set MyOutproc = new MyLibrary.MyOutProcServer ' What is invoked in this
case, EXE or DLL? Same.
---------------
So what's the
point? I need both in-proc and out-of-proc to be registered at the
same time and be distinguishable from one another.
The example above won't preclude that.
The single type library in the first case, and the shared type
library in the second, would be packaged as a standalone TLB file...
-----------------
Could you elaborate on this? I've attempted this approach but end up
with shared.tlb being something like 500k and in-proc/out-of-proc.tlb
being about 3k.
Why is that surprising? They only contain the coclass and the reference to
the shared TLB.
---------------
I guess I was hoping that importlib acted like including a header. Maybe I
should be using import on the shared.idl? If so, what would that entail?
---------------
Here's my out-of-proc idl:
[ uuid("SOME-GUID-HERE"), version(1.0),
helpstring("MyApplication 1.0 Object Library") ]
library MyAppLibrary
{
importlib("shared.tlb");
interface _IDualMyApp;
This declaration shouldn't be necessary.
[
uuid("SOME-GUID-HERE"),
version(1.0),
helpstring("Global Application Object"),
appobject
]
coclass Application
{
[default] interface _IDualMyApp;
};
};
for in-proc idl:
[ uuid(SOME-DIFFERENT-GUID-HERE), version(1.0),
helpstring("MyDLL 1.0 Object Library") ]
library MyAppLibraryX
{
importlib("shared.tlb");
interface _IDualMyApp;
[
uuid(SOME-DIFFERENT-GUID-HERE),
version(1.0),
helpstring("Global Application Object"),
appobject
]
coclass Application
{
[default] interface _IDualMyApp;
};
};
All other interfaces (including _IDualMyApp), coclasses, UDTs, enums,
etc. are in the shared.tlb. The .idl files compile fine but when I
compile my C++ code, none of them are recognized, giving 3000+
errors.
Are you using #import in your C++ code? Unfortunately, #import doesn't
automatically follow references between TLBs. You'll have to #import
"shared.tlb" explicitly.
---------------
No, I'm not using #import and would prefer not to. I bind the two unique
typelibs shown above as a resource in both EXE and DLL.
---------------
I assume this is where the "would be packaged as a standalone
TLB file" comes in. So how do I go about doing that?
When you compile shared.idl, a file named shared.tlb is produced.
---------------
I know this. I don't want to have to distribute this shared.tlb or any .tlb
for that matter. I don't really want anything to change from the end users
perspective. They open up some VBA aware app, add a reference to our product
which is listed as it always has been and code away.
Maybe some background info is required here. The application started out as
an MFC application with no automation. Later, it was decided to add
automation support. Later still, the requirement was added that we should
have a seperate DLL version of our ATL/COM interface. Being somewhat naive,
perhaps, I pretty much just copy/pasted the entire contents of the .odl(EXE
project) to the .idl(DLL project) and changed all the GUIDs in the .idl.
This has been working fine for several years. Now the requirement is that
both the EXE and the DLL share as much of the .idl file as possible. IOW,
have as few unique GUIDs as possible between them and also have them be
registered at the same time so that the end user can choose which COM server
they want to use.
---------------
Thanks again for all your help,
Drew