I have a c# .net DLL that I use from a VB6 app. It exposes an event,
and the VB6 app is sinking it.
The VB6 app is receiving the event, as long as it is raised from the
main thread of the .net DLL.
I have an aync task being handled inside the DLL (delegate BeginInvoke). Any
attempt to raise the event from within that thread casuses the reported
error, even from within the AsyncCallback function, when the thread is ending.
I noticed that the delegate for the event is not declared inside the
interface. It's in that module, but above the interface definition:
[ComVisible(false)]
public delegate void LoggingEventHandler( string logData );
The event is declared in the class itself as:
public class Processor : _Processor
{
public event LoggingEventHandler LogNotification;
Finally, to raise the event:
if ( this.Completed != null )
this.Completed( true );
If I open the tlb with OLEVIEW, I can see the public event just fine. Of course, I expected to, as it's working up until the helper thread kicks in.
Now for the REAL WIERD PART! This DOES work on several servers that have
been in production for months. It's just this one server that it won't work
on. Same code. Resinstalled/registered it 1,000 times. It took me a while to
find that an error was even occuring, since it was being raised in the
seperate thread. In other words, I'm receiving the event just fine on a series of servers. This is a new machine we're trying to bring online. I suspect it's environmental, but I can't figure it out.
I don't understand why the publisher would be expecting a certain type of
subscriber in the first place... unless the error is really triggered by the client when the event reaches it. I've put logging into the client, though, and the first line of code inside the event is not being executed.
For the VB6 app, I reference the tlb file that is automatically created when
I compile (Interop is checked). I unregistered and re-registered the tlb on
the server. I regasm'd the dll itself. All dlls are in the same folder - not
in the GAC.
The stack trace is as follows:
at System.RuntimeType.InvokeDispMethod(String name, BindingFlags
invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32
culture, String[] namedParameters)
at System.RuntimeType.InvokeMember(String name, BindingFlags invokeAttr,
Binder binder, Object target, Object[] args, ParameterModifier[] modifiers,
CultureInfo culture, String[] namedParameters)
at System.RuntimeType.ForwardCallToInvokeMember(String memberName,
BindingFlags flags, Object target, Int32[] aWrapperTypes, MessageData&
msgData)
at HPFS.Queue.IProcessorEvents.LogNotification(String logData))
and the VB6 app is sinking it.
The VB6 app is receiving the event, as long as it is raised from the
main thread of the .net DLL.
I have an aync task being handled inside the DLL (delegate BeginInvoke). Any
attempt to raise the event from within that thread casuses the reported
error, even from within the AsyncCallback function, when the thread is ending.
I noticed that the delegate for the event is not declared inside the
interface. It's in that module, but above the interface definition:
[ComVisible(false)]
public delegate void LoggingEventHandler( string logData );
The event is declared in the class itself as:
public class Processor : _Processor
{
public event LoggingEventHandler LogNotification;
Finally, to raise the event:
if ( this.Completed != null )
this.Completed( true );
If I open the tlb with OLEVIEW, I can see the public event just fine. Of course, I expected to, as it's working up until the helper thread kicks in.
Now for the REAL WIERD PART! This DOES work on several servers that have
been in production for months. It's just this one server that it won't work
on. Same code. Resinstalled/registered it 1,000 times. It took me a while to
find that an error was even occuring, since it was being raised in the
seperate thread. In other words, I'm receiving the event just fine on a series of servers. This is a new machine we're trying to bring online. I suspect it's environmental, but I can't figure it out.
I don't understand why the publisher would be expecting a certain type of
subscriber in the first place... unless the error is really triggered by the client when the event reaches it. I've put logging into the client, though, and the first line of code inside the event is not being executed.
For the VB6 app, I reference the tlb file that is automatically created when
I compile (Interop is checked). I unregistered and re-registered the tlb on
the server. I regasm'd the dll itself. All dlls are in the same folder - not
in the GAC.
The stack trace is as follows:
at System.RuntimeType.InvokeDispMethod(String name, BindingFlags
invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32
culture, String[] namedParameters)
at System.RuntimeType.InvokeMember(String name, BindingFlags invokeAttr,
Binder binder, Object target, Object[] args, ParameterModifier[] modifiers,
CultureInfo culture, String[] namedParameters)
at System.RuntimeType.ForwardCallToInvokeMember(String memberName,
BindingFlags flags, Object target, Int32[] aWrapperTypes, MessageData&
msgData)
at HPFS.Queue.IProcessorEvents.LogNotification(String logData))