Re: distributing a COM library/server for use by other folks for C++
A type library can only represent a subset of all that can be
represented in IDL. It's the poor man's choice if you don't
have the original IDL. It certainly suffices for Automation-
compatible interfaces though.
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================
"Heinz Ozwirk" <hozwirk.SPAM@arcor.de> wrote in message
news:44a4466f$0$29136$9b4e6d93@newsread4.arcor-online.net...
"Jason S" <jmsachs@gmail.com> schrieb im Newsbeitrag
news:1151587232.372100.168520@b68g2000cwa.googlegroups.com...
If I have my compiled COM library/server (.dll for the purposes of this
discussion; could also be an .exe), what other file(s) are the best way
to distribute this for use by other people in their C++ clients? (Many
of us here are using MSVC 6.0, not sure if the answer is different for
more recent MSVC versions)
As far as I can tell, I can take just the .dll and the _i.c file
produced by MIDL, when I build the server. Then I can #import the .dll
and #include the _i.c file (for CLSIDs, somehow I can't seem to use
just the .dll file) & everything seems to work dandy.
You need your dll or exe, all the dll's used by your library/server and,
for an exe server, the type library (TLB). There's no need to ship the i.c
file as well. Users of your library can generate the IDs with #import or
simply use __uuidof(...). The IDL contains nothing that is not in the type
library and which can be viewd with apps like OleView. But if your library
implements interfaces that are not automation compatible, you should
create and ship the proxy/stub dll.
Or I can #import the .tlb file instead of the .dll;
Yes.
HTH
Heinz