Question

I don’t know if this is a bad idea or not. I’m using an unmanaged DLL (written by me) in C#.

There are some callback functions that can be set up in the DLL, but these can only mapped to static class members on the C# side.

Since I want to make a callback operate on a particular class instance I’m wondering if it would be safe to store a class instance pointer inside the DLL’s state information.

From the DLL’s perspective this will simply be a 32-bit context integer, but from the C# side this will be an actual class “pointer” or “reference”, with the callback signature defined something like so:

public delegate void StatusChangeHandler(ContextClass context, int someCallbackValue);

It does compile and it does appear to work, I just don’t know if this is guaranteed. Is this an acceptable practice?

Answer 1

One problem that I see here, is that .Net have a garbage collector, which can move your class around. So your saved pointer may be invalidated. In order to prevent this for simple types you should pin the object like this:

byte[] b = new byte[1000];
// pin b, and get pointer to the first element.
fixed (byte* ptr = &b)
{
   //use your fixed pointer to b. b will not be moved untill code leaves fixed region.
}

Though, for complex types, .Net may be smartenough to pin objects automatically, I would not rely on that.
So you have write something like this:

var ctx = new Context();
fixed (IntPtr ptr = &ctx)
{
    StatusChange(ptr);
    // do other stuff, and don't leave fixed region, until you can clear the pointer in the native library.
}

But really, I think a much simpler and reliably way will be to create a static dictionary for your context objects, and give your native dll only a key for that dictionary, which could be a number, string or GUID. E.g. anything that is a value, not a pointer.