Using DirectX DLL (C++) from C#

Question

I have a native C++ DLL using DirectX, that I want to be able to use through C# to be able to create content creation tools.

Adding COM would require quite an effort it seems. Can P/Invoke be used to maintain classes using polymorphism, or would it require me to wrap most of the code to facilitate use of P/Invoke?

It there a better solution is available? Or should I even consider writing the tools in C++ using Qt perhaps?

Christie

Answer 1

I always feel that C++/CLI is always the best option when doing C# to C++ interop. You can easily create thin wrappers for an unmanaged library that will look exactly like a managed library to your C# code. It also gives you more control over how marshaling and pinning is performed.

There are ways to automatically generate C++/CLI I believe, but I've never used them.

More info on C++/CLI here: http://msdn.microsoft.com/en-us/magazine/cc163681.aspx

Vinasse

Both answers seems like valid options, but I went with this approach so I mark this one as the answer.. – Christie

Answer 2

I presume rendering with D3D directly from C# isn't an option? (because that certainly would be easier!)

A long time ago, I used SWIG to automatically maintain C# "bindings" of my C++ rendering DLL code. It uses P/Invoke to expose the C++ objects on the C# side, and you won't have to maintain that code anymore.

Shore

No, D3D from C# isn't an option for me. So SWIG creates both C++ wrapper and the C# code to use the wrapped functions/classes? – Christie

SWIG can be used to create and maintain the C# wrappers required to expose your C++ objects. You just have to write a separate interface definition file (which can include your original C++ header) to describe how the objects/functions are exposed to C#. SWIG handles most of the tricky details (P/Invoke, parameter marshaling, etc). Look at their tutorial page, you'll "get" what it does very quickly. It does increase the complexity of the resulting system (and it's one more tool to learn!), but if you don't have a choice, it certainly beats hand-coding the wrappers... – Shore

Answer 3

You don't need to write wrap on QT.

I advice you to write Observer class both in C# & C++, and hide calls of Native functions to it. Schema is like this

Your code in C# -> Observer(C#) -> Native call to Observer(C++) -> Calls to your dll.

Capper

Never said that I needed to wrap QT.. And what would the advantages of Observer classes be over just using: C# -> C++/CLI -> Native DLL? – Christie

@Daniel Maybe i haven't understand your suggestion about QT. An observer is not better, he is an alternative for you. It's your choice by what language you should write calling layer. – Capper

QT wasn't relevant to my question, it was just a side-note of my intent if there was no non-trivial way to implement C#/C++ interoperability. About the Observer, why would you suggest it as an alternative if you didn't think it was a better solution? – Christie

It's only better because you don't need to learn C++/CLI language, even just for this small case. In my opinion C# for the layer of calls, C++ for implementation. The third is not needed. C++/CLI is just another .NET language, but with syntax of C++, so, why not to use C# for calling. – Capper