How do I wrap multiple unmanaged C++ classes in a COM object?

Question

0.00/5 (No votes)

See more:

It's been a (long) while since I've been in the world of Microsoft COM.

I've got a couple of classes (FooA and FooB) which are part of a static unmanaged C++ library.

Rather than figuring out the nightmare of header file inclusion resolution, I'd like to wrap this library in a COM object. Doing so would make the library available for consumption by C# (managed) clients.

The 1st pass of the COM object is to be single thread apartment (we might switch to multi thread later).

This is where I'm a little rusty and get a little confused.
I have classes FooA and FooB contained in the library.
FooA and FooB have methods which I'd like to expose to clients.

C++

class FooA {
  public Method1;
  public Method2;
}

class FooB {
  public Method3;
  public Method4;
}

How do I expose those classes and methods their methods through a COM interface?
Ultimately I need an instantiation of the class (an object) to reference methods on that object.
Do I need to return and pass around a ptr to the instantiated object to interfaces exposed on the COM object?

A lot of the examples I've seen are pretty standard: add/multiply two integers

Can someone shed some light on this for me and perhaps point me towards a useful example?

Thanks,
JohnB

Posted 8-Dec-14 16:49pm

johnbMA

Add a Solution

Comments

George Jonsson 8-Dec-14 23:07pm

Have you considered to create a library in managed C++ instead?
Then you skip the hassle to translate all function calls, structs and defines into c# but you can easily import the library into a managed project.

johnbMA 9-Dec-14 9:53am

::>George::> Managed C++ is not an option in this implementation. All other components of the solution are in the unmanaged space. I don't want to incur the cost of the unmanaged/managed boundary.

George Jonsson 10-Dec-14 3:30am

But you said the library will be consumed by a managed client.
I got the impression that you want a COM library as a bridge between unmanaged and managed code.
I simply suggested an alternative approach that might be easier to implement.

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Shmuel Zang · Answer 1 · 2014-12-08T18:23:00

You can achieve that goal by creating one interface that contains the whole of the methods and, a class that implement that interface and call the methods in the original classes.

But, if your goal is exposing a native code to be used by C# clients, you can use P/Invoke or C++/CLI instead. You can read more about it in my CP article about: Exposing native to managed - C++/CLI vs. P/Invoke.