While researching for ongoing/upcoming projects that will need approaches for interop between .NET and native code, specifically, for native code to call into .NET code, Reverse P/Invoke has come to my attention as a viable option. Of course there is the official Microsoft recommendation to expose .NET classes as COM components, which are then callable from native code that talks COM.
The Reverse P/Invoke approach allows native code to call into .NET delegate using a function pointer. So it could work well for my requirement, for which I need a way to fire an event from the native app to the .NET app, for instance, an application context change on the native side must be reflected on the .NET side.
The blog by Junfeng, however, does not give a concrete example of such Reverse P/Invoke approach. So I came up with a POC, where I had a VS.NET solution with three projects: (1) a native console application (C++ project) (2) a managed class library (C# project) and (3) a mixed mode dll library with exported C++ function (C++/CLI project).
So this POC is trying to simulate a native application (#1) that needs to notify managed code (#2) of data changes. I came up with a dll library compiled with /clr switch to handle the interop details. Both the native app and the managed code requires very minimum changes.
On the .NET side, we have a managed class that has a Foo() function and a GetDelegate() function that hands out a delegate to Foo to its caller.
public class ManagedClass
private CallBackDelegate _delegate;
_delegate = new CallBackDelegate(this.Foo);
public CallBackDelegate GetDelegate()
public void Foo(EventData data)
The EventData is a data structure that shares the same binary layout as the one that will be created and marshaled from the native code.
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
public struct EventData
public int I;
public string Message;
And here is the delegate definition. Note the attribute UnmanagedFunctionPointer with the calling convention.
public delegate void CallBackDelegate(EventData data);
In the mixed mode dll, here is the definition of the EventData data structure and function pointer:
// data structure for the callback function
// callback function prototype
typedef void (*NativeToManaged)(EventData data);
And the exported function is defined as in the following. Note how the .NET delegate gets invoked through the function pointer.
#define INTEROPBRIDGE_API __declspec(dllexport)
INTEROPBRIDGE_API void fnInteropBridge(EventData data)
ManagedLib::ManagedClass^ c = gcnew ManagedLib::ManagedClass();
IntPtr p = Marshal::GetFunctionPointerForDelegate(c->GetDelegate());
NativeToManaged funcPointer = (NativeToManaged) p.ToPointer();
// invoke the delegate
Now in the native app, I have code that creates a copy of EventData and invokes the .NET code through the exported dll function fnInteropBridge:
// forward definition of the API function
void fnInteropBridge(EventData data);
int _tmain(int argc, _TCHAR* argv)
data.I = 50;
data.Message = L"Hello from native code!";
In summary, I like this approach it that it provides quite an easy and non-invasive way for native code to call into managed code. It should especially work well in my scenario, where application context changes initiated from the native app needs to be propagated to the managed code. Furthermore, besides polishing this up, I think I will add code to raise a .NET event from inside ManagedClass.Foo(). Then all interested .NET citizens on the managed app side can subscribe to it.