Identify the Excel instance that you are using and then use the Windows api
to kill it. This is the only reliable way to kill Excel. You can wait for
GC and so on, but Excel is like the cat that came back. You have to use
sheer brute force to be absolutely sure that it's dead.


--
www.alignment-systems.com


"Fredrik" wrote:

We are building a COM addin using C# and .NET 1.1, targeting Office XP
and Office 2003. We are not using VSTO.
The purpose of the COM addin is to do some custom work when certain
XLS-documents are loaded (such as showing a custom toolbar, etc)
The COM addin works fine when Excel is running stand-alone. But when
Excel is running inside Internet Explorer, Excel remains running after
IE is closed.
I guess this is due to the fact that we hold references to Excel from
within the addin. The problem is that I don't understand how I can
avoid this, if the addin should work as expected.
There's a catch-22 he In order for Excel to unload when IE closes,
all references to it must be released.
However, for my addin to release the references,
IDTExtensibility2.OnDisconnection must be called, which doesn't happen
until Excel closes.

Any ideas:

Here's the pattern we use (simplified):

public void OnConnection(object application, ...) // Implementation of
IDTExtensibility2
{
applicationObject = (Excel.Application)application; // Save the
app-object for later
}

public void OnStartupComplete(ref System.Array custom)
{
applicationObject.WorkbookOpen += new
Microsoft.Office.Interop.Excel.AppEvents_WorkbookO penEventHandler(applicationObject_WorkbookOpen);
}

public void OnDisconnection(...)
{
applicationObject = null;

GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();
}

public void OnBeginShutdown(ref System.Array custom)
{
TearDownUI();

GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();
}

private void
applicationObject_WorkbookOpen(Microsoft.Office.In terop.Excel.Workbook
wb)
{
SetUPUI();
}


Thanks!
/Fredrik