Managed code, such as C# or VB.NET, provides native access to classes, methods, and types defined within the libraries that make up the .NET Framework.
When the unmanaged data types become too complex for a simple implicit conversion from and to managed types, the framework allows the user to define attributes on the function, return, and/or the parameters to explicitly refine how the data should be marshaled so as not to lead to exceptions in trying to do so implicitly.
As a result, a programmer with only managed code experience will need to brush up on programming concepts such as pointers, structures, and passing by reference to overcome some of the obstacles in using P/Invoke.
Using native DLLs means that the programmer can no longer benefit from type safety and garbage collection as is usually provided in the .NET environment.
Significant performance gains result from having eliminated any needless context switching, memory requirements are reduced (shorter stacks).
Brad Abrams has this to say on the subject:[4] The problem lies with C++ functions like the following: What type should we use for the parameter params in our P/Invoke signature ?
One of the tools listed below, xInterop C++ .NET Bridge has resolved this issue by implementing multiple overrides of the same C++ method in .NET world, developers can then pick the correct one to make the call.
It overcomes the ambiguity problem by wrapping native pointer function parameters in PInvoker specific .NET interface classes.
For instance, if we consider the above example code, PInvoker would produce a .NET P/Invoke function accepting a .NET interface class wrapping the native char * pointer.
Microsoft Interop Assistant is a free tool available with binaries and source code available for download on CodePlex.