views:

127

answers:

4

Thus far I've figured out out I needed to recompile the library as a .dll instead of a .lib, enable /clr and /EHa instead of /EHsc. Now I've got a managed dll which I've added as a reference in my C# project.

Now how do I use it?

I'm prepared to write some wrappers, but I don't know where to begin or how to "see" what functions I've gained access to. I've read a little bit about how the class names and functions might be mangled by the compiler... do I need to go back and add __declspec exports everywhere (if so, how?), or is there an option in VS2010 that says "don't mangle it!"?

The C++ library in question is still under active development, so I'm hoping I can modify the C++ library as little as possible and just recompile it periodically with a few switches, and then expose the new functionality as I need it.

+7  A: 

If you are going to compile your C++ (if originally was unmanaged C++) you will need to do much more than just add the /clr switch. In order for C# to use the DLL you will need to create managed classes and other types based on CTS which are compatible with C# (.NET).

See and ref classes.

A good book to read about the subject (IMHO) is this one

Anders K.
So... to create the managed classes, do I need to do that in C++/CLI, or what? I need a bit more to go on.
Mark
yes you need more to go on, I would suggest checking out the links. There are also some tools to convert C++ to managed C++ from Microsoft, this may help as well. Check out this: http://stackoverflow.com/questions/151776/are-there-any-tools-for-converting-managed-c-to-c-cli
Anders K.
+4  A: 

You can either expose the functions as C style functions (i.e., no mangling) from your dll or you can expose them as COM objects.

Ed Swangren
How do I use them as COM objects?
Mark
+4  A: 

I'd suggest writing a COM wrapper, and using that instead. Have a look at http://msdn.microsoft.com/en-us/library/035x3kbh%28v=VS.80%29.aspx for intro instructions. You'll want to make your object interfaces derived from IDispatch and be automation compatible, which should enable the runtime to consume them without any custom marshaling.

A nice benefit of this approach is you can continue to build your native code as a library, and just make your COM project use it. Also, it's still native code inside the COM object, so there's much less potential for unknown problems (once you get the interface layer working).

That's my suggestion, anyway.

Nick
+1  A: 

Yes, wrap it in à COM object. I believe ATL is what you meed to do this with the least effort.

H. den Breejen
ATL? You're talking to someone who has never done this before.
Mark
ActiveX Template Library. It's part of the MS development environment, and used for creating COM objects in C++.
H. den Breejen