Hi,

I am developing a ASP.NET application which uses a 3rd party API that
is an unmanaged C++ DLL. The possible solutions that I have in mind to
build the .NET to C++ bridge:

1. Import the unmanaged C++ DLL in the .NET (C#) program and call the
functions as static entry points exposed by the DLL. This would be very
cumbersome as it wont let the .NET app have a Object Oriented design.

2. Build a COM wrapper using C++ around the unmanaged DLL and import
these COM components in the .NET project as a reference. There's still
an issue of converting C++ standard and custom data types to sth that
..NET understands. .NET interop would sure help marshalling standard
datatypes(string, int, char etc..) but what about the custom datatypes?

3. Code the .NET application in C++ and use the C++ API directly (or
through a COM layer as in point 2 above).

Personally I think approach 2 should be the best in terms of
application extensibility and maintainability.

Any pointers regarding this would be helpful.

Thanks

dydrmr <vzkapoor (AT) gmail (DOT) com> wrote:

4. Build a CLR wrapper using C++/CLR, and then write the app in C#.

HTH/Ole Nielsby

Also keep in mind that managed-unmanaged interop is quite expensive.
When you call the C++ code a lot it's best when you do that from
unmanaged code.
Also the C++/CLR interop is way faster than the C# interop.

Regards,
Dirk

<Kappa007 (AT) hotmail (DOT) com> wrote


Hmmm "way faster " Any figures that prove that claim?
No managed code can directly call into unmanaged code, be it MC++ or C#, the
first time you call a native function the CLR creates a stub for the
function to be called (amongst many other things), this stub is the same
whether you call from C# or C++/CLI (the CLR known nothing about these high
level languages), once the stub is in place the same stub will be reused for
the next calls of the (same) function.
Only difference between C# and managed C++ calling into native code is the
security check performed for PInvoke interop, this security check can be
skipped by applying the [SuppressUnmanagedCodeSecurity] attribute. With
this attribute applied the call overhead is the same for all
managed/unmanaged code transitions. Only advantage of Managed C++/ native
C++ interop over PInvoke interop is the level of control when marshalling
arguments from managed to native, but in general this advantage is rather
small.

Willy.