that should create a ".tlh" file in your Debug/Release folder. If you look
in that file, it should give you a COM definition of the interface. With
you call from your .Net version. e.g.
DLL? (Search MSDN for "Importing a Type Library as an Assembly").
There should be a way to do it... it seems silly to create a .Net DLL just
to do this...
Thank you Bob,
You got me right, i.e. "MFC exe calls C# managed DLL which in turn
calls other ...COM Server. I don't know how it was written. I wouldn't
use C# COM, to call this third party COM, if I new how to expose it to
my MFC application. This third party didn't provide any
documentation. They just gave some exe (which I cannot find now,
stupid I'm). If I run this exe on my machine (just double click it)
it registered their COM, after this from .NET project on the same
machine I could add corresponding reference to my C# project and use
it. In VS6 there is now this feature. I'd asked them about some
CLASSID or PROGID to be able to CreateInstance() directly from my MFC
project and use it, but didn't get anything from them. So I had to
use the method they suggested - call functions of their COM server
from .NET application.
Here is my code in C# COM:
MyCOMFunction()
{
ThirdPartyServer.Server tps = new ThirdPartyServer.Server ();
tps.SomeFunction(...);
}
Here is my code from MFC application;
#import "csharcom.tlb"
............................................................
............................................................
............................................................
............................................................
............................................................
CoInitialize(NULL);
CSharpCOM::Test_InterfacePtr pCom(__uuidof(CSharpCOM::TestServer));
pCom->MyCOMFunction();
Again, I think the problem is to register this third party COM Server
on a "clean machine".
Thanks again,
Alex
On May 13, 10:49 pm, "David Ching" <d...@remove-this.dcsoft.com>
wrote:
"Bob Eaton" <pete_dembrow...@hotmail.com> wrote in message
news:efP2fNSlHHA.4644@TK2MSFTNGP03.phx.gbl...
All the COM and .Net DLLs must be registered on the "clean" machine or
they
won't be able to talk to each other (unless you go "Registry Free
COM"--search the MSDN site for "Reg-Free COM").
Much thanks for this pointer for "registry free COM". I had not heard of
this before and am crossing my fingers it will help me deploy my Vista
gadget which relies on an ActiveX control. It would be so much easier
not
have to register that control, especially since the gadget needs to be
used
in Limited accounts.
-- David- Hide quoted text -