Mixing Cpp and C# -- Calling Cpp-Class-Interface from C#

[Tomerland]

Dear gurus, I found so much on the subject of calling a Cpp-Interface from C#, but I'm more confused now. There is no simple/understandable example. My problem: I have legacy-code which contains Cpp-Classes in "old-fashioned Cpp-Dll's" and I want to call interfaces of these classes from within C#-Code. Kind regards

[rah_sin]

u can use DLLIMPORT from c# code

rahul

[nelo_]

I don't think you can do that directly. You will have to write a C/C++ interface that will call the functions in the C++ classes. When you write your interface be careful to choose data types that will be easily marshalled by .NET.

[Dave Kreskowiak]

Tomerland wrote:

I have legacy-code which contains Cpp-Classes in "old-fashioned Cpp-Dll's" and I want to call interfaces of these classes from within C#-Code.

You can't do this directly. The classes in your C++ code have to be exposed through COM to get this to work. If they're not, you'll eitehr have to rewrite the C++ code so that they are, or write a wrapper that takes care of using the C++ classes and exposes various methods to manipulate them through COM. Managed code cannot directly instantiate and use unmanaged code classes without a Runtime Callable Wrapper of some kind.

Tomerland wrote:

There is no simple/understandable example.

Correct. That's because this is a difficult concept to understand.

A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
     2006, 2007, 2008

[Tomerland]

A principal question. I'm dealing with number-crunching applications having a rich user-interface. To realize these applications I use a two-folded strategy: a) use highest-speed technology as unmanaged code,C++, pointers or assembler b) for the rich user-interface I want to use window-forms or wpf. In previous days this was no problem. I used MFC; there is no integration-problem with different technologies. But now, I have a mess. Mixing C++ and C# seems to be incredibly problematic. If you - dear reader - have a similar type of applications, how do you solve these issues? Are you really stepping into the realm of interoperability? Kind regards

[Dave Kreskowiak]

Tomerland wrote:

If you - dear reader - have a similar type of applications, how do you solve these issues?

I've already explained how to solve them.

Tomerland wrote:

Are you really stepping into the realm of interoperability?

That's the only option you have.

A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
     2006, 2007, 2008

[carbon_golem]

I'll give a little very simplified example to try to get you started. Use caution when dealing with unsafe code/pointers going back and forth across the managed boundary. The garbage collector can change reference locations on you as your dll is working, in that case you'll need to "pin" or use the fixed block especially when dealing with *buffers. say you have a .dll named "TheDll.dll" with one method: public int Add(int a int b); //...``internal static class TheDllNativeMethods{ [DllImport("TheDll.dll")] //tells the runtime to look in this dll for that method public static extern Int32 Add(Int32 first, Int32 second); } public class YourClass{ public Int32 ForwardingAdd(Int32 a, Int32 b){ return TheDllNativeMethods.Add(a, b); } }

"Run for your life from any man who tells you that money is evil. That sentence is the leper's bell of an approaching looter." --Ayn Rand

[Tomerland]

People often talk about legacy code as something like the "necessary evil"; it should be substituted by newer technologies as C# (or Java) if possible. This may the right in many cases, but for number-crunchers such "legacy" is not obsolet, it is the only choice, because the performance of C# (Java) is much to slow Kind regards