COM component in Managed C++

[iyengar.sheshadri]

Hi All,

Currently we have COM component(dll) implemented using ATL.
Because of the current business requirements, we would like to rewrite
the COM component in Managed C++ and the clients will be unmanaged C++
and C# .

I have been searching net to find some sample code and but could not
get it.

Please give me some pointers on how to implement COM component in
Managed C++.

Thanks a lot.
Shesh

[SvenC]

Hi,

>
Currently we have COM component(dll) implemented using ATL.
Because of the current business requirements, we would like to rewrite
the COM component in Managed C++ and the clients will be unmanaged C++
and C# .

I have been searching net to find some sample code and but could not
get it.

Please give me some pointers on how to implement COM component in
Managed C++.

Why would you want to do that? If you want to create COM objects in VC++ and
use them also in C# then write unmanaged COM objects and have tlbimp produce
the .Net COM wrappers.
What would be the benefit of using Managed C++ here? At least I guess you
wanted C++/CLI the successor of Managed C++?
If you want to use the .Net framework to implement the component then just
use C# and make it COM-visible. That COM component can then be used with
#import in VC++.

--
SvenC

[iyengar.sheshadri]

On Jul 17, 11:35 am, "SvenC" <[e-mail]:

Hi,

Currently we have COM component(dll) implemented using ATL.
Because of the current business requirements, we would like to rewrite
the COM component in Managed C++ and the clients will be unmanaged C++
and C# .

I have been searching net to find some sample code and but could not
get it.

Please give me some pointers on how to implement COM component in
Managed C++.

Why would you want to do that? If you want to create COM objects in VC++ and
use them also in C# then write unmanaged COM objects and have tlbimp produce
the .Net COM wrappers.

We would like to modify the current component to use a new C# Parser
library and this
component shall be used by a new framework(managed). Along with this,
we need to
support existing clients without making any changes to them.
So, we thought we could avoid a lot of marshaling by rewriting the
code in managed world.
(current component uses safearrays, bstr...)

What would be the benefit of using Managed C++ here? At least I guess you
wanted C++/CLI the successor of Managed C++?

Initially we thought a lot of code in the COM component can be reused.

If you want to use the .Net framework to implement the component then just
use C# and make it COM-visible. That COM component can then be used with
#import in VC++.

Currently the COM interfaces and their implementations are in separate
dlls.
Would it be possible, to implement those interfaces in C# by importing
the types
in the tlb file, so that we can keep the interfaces separate? (current
clients
depends on these interfaces and we don't want to change them).
Does it makes sense to you? Please suggest me.
Thanks a lot for helping me.

>
--
SvenC

[SvenC]

Hi,

Currently the COM interfaces and their implementations are in separate
dlls.

That was a very good decision which should pay back now.

Would it be possible, to implement those interfaces in C# by importing
the types in the tlb file, so that we can keep the interfaces separate?
(current
clients depends on these interfaces and we don't want to change them).
Does it makes sense to you? Please suggest me.

Yes, that should be possible. Just leave all interface definitions in a
separate dll, where you control the COM interfaces in an IDL file.
That should give you enough control not to break anything for older clients.

--
SvenC