I have an Outlook COM-Addin written in VB.NET but that utlizes a few legacy VB6 libraries.
When I run the application via Outlook, everything works fine however when the .NET add-in library is loaded out of process (called via a third party application) I'm running into one specific issue that I can't seem to remedy.
The VB6 library handles a lot of the Outlook API work and fires back events (via RaiseEvent) to .NET when certain conditions are met. For some reason, when running out-of-process, one specific event, in one specific instance, is simply SWALLOWED and the execution of the app is simply halted. Not frozen, as the .NET UI thread is responsive, but that underlying code path stops cold as soon as it steps into the VB6 RaiseEvent call.
I experience the same behavior when I walk through as well in the debugger. I step into the event (in VB6) and nothing ever surfaces on the other side.
Note, the event does fire successfully once or twice prior to this during the execution of the app, so it's not a wholesale issue with the event per-se, but simply this one specific instance in which RaiseEvent is called. It's so odd.
The MAJOR problem for me is that no error is raised. I bookended the RaiseEvent call with all sorts of error handling - on the VB6 end and .NET - and NOTHING is raised. I have trace logs set up on the first line of the event handler in .NET and directly before and after the RaiseEvent call in VB6 and the only line that is ever recorded is the one that directly precedes the RaiseEvent.
One of the only unique elements about this problematic code path that I can discern is that two disparate events are fired rather quickly back to back (the second of which being the one that fails). I tried adding a sleep call to no avail.
I'm just not sure what I can do to further diagnose this issue. I'm not explicitly spawning another thread for VB6 execution although I'm inclined to believe .NET is under the hood.
If anyone has any suggestions on how I might be able to diagnose this issue, I'm all ears as I've just about run out of ideas.
UPDATE: The issue was in some way related to passing an ContactItem object into the first event from VB6. I didn't need the entire object, only a property, so I sent a string across in lieu of the entire object and sure enough it now works. .NET/COM fun.
Thread.CurrentThread.ManagedThreadId
at the point where you create the legacy VB6 object and anywhere you call it. Also anywhere you handle its events on the .NET side. DoesManagedThreadId
remain the same everywhere? – noseratio