需要将基于C ++ dll / h / lib / xml / exe的SDK“包装”到COM中以在C＃2.0项目中使用

Question

I just got handed an SDK made of C++ dll, lib, exe, and various .h files. I presume it is meant for C++ developers. The sample projects they provide with their documentation are all written in C++. I am able to spin them up with Visual Studio 8 (2005) and run them. They do control the device as advertised. However the project this needs to be used by is in C# .Net 2.0 and that is unchangeable.

My boss was a C++ developer and says all I need to do is to compile it as a COM object and then import the COM object into my C# solution. My boss says it should take less than an hour to "wrap" there SDK up as a COM object, even for me with no knowledge of C++ compiling.

I've used COM objects in C# solutions before so once this is made, I can continue on from there without a problem.

However, I don't know what to do to make the COM object from the 2 .dll files, 1 .exe, 1 .lib file, 1 .xml file, and the 12 .h files. Is there a resource available to tell me what to do to make this happen?

Answer 1

My boss was a C++ developer and says all I need to do is to compile it as a COM object and then import the COM object into my C# solution.

That's true, however compiling it as a COM object is "difficult" (by which, I mean that you can't do it) unless it already implements the COM APIs (if it doesn't then you need to implement the COM APIs before you can build it as a COM object).

There are books (for example, Essential COM ) which explain how to to create COM objects using C++, but it's non-trivial (for building COM objects there may be better books than Essential COM , and better/easier tools than C++).

I think you and/or your boss have 3 options:

1. Ask the vendor to give them to you as COM objects
2. Design a COM API that would wrap the SDK's API. Create a COM project (in the language of your choice) which exports this API. Implement these APIs by invoking the underlying SDK methods. To do this you may need someone who knows C++, or be willing to spend much, much longer than "an hour" on this project.
3. Forget about using COM; instead, build the SDK as a DLL, and use PInvoke to invoke it from .NET code.

My boss says it should take less than an hour to "wrap" there SDK up as a COM object, even for me with no knowledge of C++ compiling.

Based on what you've said I don't know of any way to make that happen.

Answer 2

Tell your boss if it would take him less than an hour to wrap it up, he should certainly do it: it would be a more efficient use of both your time.

I would also suggest ATL (not using attributes), but this is something which can take some time to get right if you're not experienced.

Answer 3

My boss says it should take less than an hour to "wrap" there SDK up as a COM object, even for me with no knowledge of C++ compiling.

That may be true for an experienced C++/COM developer, but not for a beginner. I think your best bet is to use ATL. Take a look at the MSDN tutorial .

And do not use attributes.

Answer 4

This doesn't quite answer your question, but...

One option instead of trying to make a COM object is to use P/Invoke and just call the methods in the DLL.

This thread on the MSDN Forums documents how to make a DLL to call using P/Invoke.

Of course if you need access to a whole class (and make an instance of said object), this isn't going to be helpful.

Answer 5

It's good that the code compiles and runs for you. That said it's totally unfair to assume you can do this in an hour.

Have you checked to see what is actually being built by Visual Studio. There could be a chance that it is already building a COM object.

Investigate how the code is being called. I assume you have a .exe that you can run to test the code. Step through this in the VC++ debugger (it's similar enough to debugging C# code) and try to identify any API calls that match with your docs/expectations. This knowledge will be helpful if you try to go the P/Invoke route.

Something else to consider is SWIG . This is typically used by Python developers to wrap C/C++ code and provides some support for C#.

The managed C++ route is probably more advisable for experienced C++ devs because you need to understand a lot about memory allocation, for all but the simplest code.

Answer 6

I (well, really my lead and I) will first try using p/Invoke (via the DllImport feature of System.Runtime.InteropServices) against the SDK's dll the company provided. I'll let you know how it goes.

Answer 7

I think what you really want/need is C++/CLI, that way you can just build them directly into a managed assembly. The idea is that you write a pretty plain wrapper that looks like kind of a cross between C# and C++ and then it does the rest.