migrating unmanaged C++ classes to provide VB interface

  • Thread starter Thread starter Brett
  • Start date Start date
B

Brett

We have an application completely written in C++ under visual studio v6. One
of our customers wants to use some of our existing components in his project
but doesn't know C++ and isn't interested in learning it. He does know C#
and VB though.

Whats the best option for us (ie. minimum work) to provide him with an API
that he can use in his own applications to access our C++ classes? I was
originally considering a COM interface, but looking into .NET, I'm wondering
if we should just upgrade the appropriate sections of code to "managed code"
so he can use that from one of his languages. What would be the easier and
most advisable path for us to take, provide an interface with COM or managed
code?

The C++ program has significant custom graphics support (based on MFC) and
has a large set of classes that are capable of controling a USB device.

Any advice is appreciated.

Thanks,
Brett.
 
We have an application completely written in C++ under visual studio v6. One
of our customers wants to use some of our existing components in his project
but doesn't know C++ and isn't interested in learning it. He does know C#
and VB though.

Whats the best option for us (ie. minimum work) to provide him with an API
that he can use in his own applications to access our C++ classes? I was
originally considering a COM interface, but looking into .NET, I'm wondering
if we should just upgrade the appropriate sections of code to "managed code"
so he can use that from one of his languages. What would be the easier and
most advisable path for us to take, provide an interface with COM or managed
code?

The C++ program has significant custom graphics support (based on MFC) and
has a large set of classes that are capable of controling a USB device.

Any advice is appreciated.

If your customer wants to use your components in .NET apps, provide a .NET
interface. If he wants to use them from, say VB6, provide a COM interface.
 
Doug Harrison said:
If your customer wants to use your components in .NET apps, provide a .NET
interface. If he wants to use them from, say VB6, provide a COM interface.

Why not just provide a COM interface and cover both bases? COM can be called
from .NET can't it?

Brett
 
Why not just provide a COM interface and cover both bases? COM can be called
from .NET can't it?

It may be more work, but if that capability is important to you, you should
look into COM interop. Here are some relevant links:

http://msdn.microsoft.com/library/d...ingcomcomponentstonetframework.asp?frame=true
http://msdn.microsoft.com/library/d...nbuildingcomcomponentsforinteroperability.asp
http://msdn.microsoft.com/library/d...ml/cpconruntimecallablewrapper.asp?frame=true
 
Back
Top