By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,199 Members | 1,721 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,199 IT Pros & Developers. It's quick & easy.

COM component in Managed C++

P: n/a
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

Jul 16 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a
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

Jul 17 '07 #2

P: n/a
On Jul 17, 11:35 am, "SvenC" <Sv...@community.nospamwrote:
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
Jul 19 '07 #3

P: n/a
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

Jul 19 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.