Unmanaged code calling vb.net callback

I am upgrading vb.net app that handles the events of a COM object (possibly written in VB6) from framework 1.1 to WPF 2.0/3.5

The code: (object names simplified for brevity)

public class MyClass
   Private WithEvents serviceMonitor As COMOBJECT.ServiceMonitor

   Public Sub New()
       serviceMonitor = New COMOBJECT.ServiceMonitor()
       serviceMonitor.Connect([some ip address])
   End Sub

   Private Sub ServiceMonitor_ServiceConnectionUp(ByVal MonitorId As Integer, ByVal UserArg As Integer) _ 
        Handles serviceMonitor.ServiceConnectionUp

        Debug.WriteLine("connection up!")
   End Sub

    ' other similar handlers omitted
End Class

The app will get the callbacks as expected, however within a few seconds I get an Access Violation. The basic callback code is similar to the .net 1.1 version although it ran perfectly.

According to my research on the error, it is caused by the garbage collector moving things around. Since I am not passing the DLL any objects to manipulate, I am guessing that the callbacks are the issues. Other folks have solved this via a delegate with <UnmanagedFunctionPointer(CallingConvention.Cdecl)> and/or Marshal.GetFunctionPointerForDelegate.

Unfortunately, all the examples I have found are cases where the DLL has some sort of SetCallback(IntPtr) method. I am using WithEvents and the Handles keyword. Here is my attempt (note that I removed the Handles keyword so that I can use AddHandler:

<UnmanagedFunctionPointer(CallingConvention.Cdecl)> _
   Delegate Sub ServiceMonitor_ServiceConnectionUpDelegate(ByVal MonitorId As Integer, ByVal UserArg As Integer)

public class MyClass
   Private WithEvents serviceMonitor As COMOBJECT.ServiceMonitor

   Public Sub New()
       serviceMonitor = New COMOBJECT.ServiceMonitor()
       del = New ServiceMonitor_ServiceConnectionUpDelegate(AddressOf ServiceMonitor_ServiceConnectionUp)
       AddHandler serviceMonitor.ServiceConnectionUp, del ' <--- Error here
       serviceMonitor.Connect([some ip address])
   End Sub

   Private Sub ServiceMonitor_ServiceConnectionUp(ByVal MonitorId As Integer, ByVal UserArg As Integer) 

        Debug.WriteLine("connection up!")
    End Sub

    ' other similar handlers omitted
End Class

The error I am getting on the AddHandler line is: "Value of type MyClass.ServiceMonitor_ServiceConnectionUpDelegate cannot be converted to COMOBJECT._IServiceMonitorEvents_ServiceConnectionUpEventHandler"

When I mouse hover the mentioned Event Handler it has a signature of: Delegate Sub _IServiceMonitorEvents_ServiceConnectionUpEventHandler(ByVal MonitorId As Integer, ByVal UserArg As Integer)

The signatures are identical so I'm not sure what the problem is.

Question 1: How do I use a delegate with AddHandler in this fashion? Question 2: Does Marshal.GetFunctionPointerForDelegate() need to be involved? It returns an IntPtr but AddHandler wants a delegate.

Thanks in advance.

回答1:

Try declaring your delegate as the delegate class expected:

   Public Sub New()
       serviceMonitor = New COMOBJECT.ServiceMonitor()
       del = New COMOBJECT._IServiceMonitorEvents_ServiceConnectionUpEventHandler(AddressOf ServiceMonitor_ServiceConnectionUp)
       AddHandler serviceMonitor.ServiceConnectionUp, del
       serviceMonitor.Connect([some ip address])
   End Sub

回答2:

Although I am not yet 100% certain that the issue is fixed, so far I haven't had any more access violations.

Basically I removed the WithEvents keyword to prevent VB from using its own COM -> .net error handling and instead used the methods in the library intended for C++ clients. I used the <UnmanagedFunctionPointer(CallingConvention.Cdecl)> and passed the library a Marshal.GetFunctionPointerForDelegate IntPtr. I also kept a reference to the IntPtr althought it may have been overkill.

I am confused that I had to go through all this since the WithEvents handlers worked perfectly in .net 1.1. The main differences was that I used a form to handle the callbacks rather than a class.

One lingering issue is the fact that the debugger sometimes stays running when I close the apps form. I am hoping it is just a debugger quirk.