We are using scripts in Excel to execute code in a VB.Net object. We want
to raise events to Excel at certain times (the object will start up
separate threads for various operations).

If the main VB.Net object raises an event to Excel directly, everything is
fine. If a thread created by the main object calls the main object via
a delegate, everything is fine.

However, if the thread created by the main object calls the main object
(via a delegate) which then raises an event to Excel (chaining the two
above actions), then Excel crashes when you try to exit, even though
the thread has long since gone away and the object reference has been set
to Nothing.

The crash is occurring because code is trying to execute in a module (DLL)
that has been unloaded. By examining the module list before and after the
crash, we've determined that the module is VBE6.DLL. It looks like this
module gets unloaded, and then someone tries to execute code in it.

Has anyone seen this before? Is there anything special that needs to be
done when invoking VB.Net objects from Excel macros to allow a clean exit?

Thanks in advance...

Jay Nabonne
Sonic Solutions

Hi Jay,

Has anyone seen this before? Is there anything special that needs to be
done when invoking VB.Net objects from Excel macros to allow a clean exit?

Sorry, but I've no idea. The only thing I can think of is that the .NET
objects have yet to be garbage-collected when Excel is closing down, so you
might be triggering an event in one of your classes that's calling into
Excel after it's shut down VBA. To test that, you could try adding an
explicit Dispose method in your .Net objects, which is called by Excel prior
to setting them to nothing. In the Dispose method, you'd explicitly turn off
the timer/event raising.

If that doesn't help, the people that know about Excel/.Net integration hang
out in the Public.vsnet.vstools.office newsgroup, so you might get a more
informed response if you ask your question there.

Regards

Stephen Bullen
Microsoft MVP - Excel
www.oaltd.co.uk