我在C#（ApplicationClass）中使用Excel互操作，并在finally子句中放置了以下代码：
while (System.Runtime.InteropServices.Marshal.ReleaseComObject(excelSheet) != 0) { }
excelSheet = null;
GC.Collect();
GC.WaitForPendingFinalizers();
尽管这种方法有效，但即使在我关闭Excel之后，Excel.exe进程仍处于后台。它只在我的应用程序被手动关闭后发布。
我做错了什么，或者是否有其他方法可以确保正确处理互操作对象？
当前回答
“千万不要在COM对象中使用两个点”是避免COM引用泄漏的一条很好的经验法则，但Excel PIA会导致泄漏的方式比乍一看更明显。
其中一种方法是订阅任何Excel对象模型的COM对象公开的任何事件。
例如，订阅Application类的WorkbookOpen事件。
关于COM事件的一些理论
COM类通过回调接口公开一组事件。为了订阅事件，客户端代码可以简单地注册实现回调接口的对象，COM类将调用其方法以响应特定事件。由于回调接口是一个COM接口，因此实现对象的职责是减少它为任何事件处理程序接收的任何COM对象（作为参数）的引用计数。
Excel PIA如何公开COM事件
Excel PIA将Excel应用程序类的COM事件公开为常规的.NET事件。每当客户端代码订阅.NET事件（强调“a”）时，PIA都会创建实现回调接口的类的实例，并将其注册到Excel中。
因此，为了响应来自.NET代码的不同订阅请求，许多回调对象被注册到Excel中。每个事件订阅一个回调对象。
用于事件处理的回调接口意味着，PIA必须为每个.NET事件订阅请求订阅所有接口事件。它不能挑挑拣拣。在接收到事件回调时，回调对象检查关联的.NET事件处理程序是否对当前事件感兴趣，然后调用该处理程序或无提示地忽略回调。
对COM实例引用计数的影响
所有这些回调对象都不会减少它们接收的任何COM对象（作为参数）对任何回调方法的引用计数（即使是被忽略的回调方法）。它们只依赖CLR垃圾收集器来释放COM对象。
由于GC运行是非确定性的，这可能导致Excel进程延迟的时间比预期的长，并造成“内存泄漏”的印象。
解决方案
目前唯一的解决方案是避免PIA的COM类事件提供程序，并编写自己的事件提供程序来确定是否释放COM对象。
对于Application类，这可以通过实现AppEvents接口，然后使用IConnectionPointContainer接口将实现注册到Excel来完成。Application类（以及使用回调机制公开事件的所有COM对象）实现IConnectionPointContainer接口。
其他回答
这里公认的答案是正确的，但也要注意，不仅需要避免“双点”引用，还需要避免通过索引检索的对象。您也不需要等到程序完成后才能清理这些对象，最好创建函数，以便在可能的情况下，在完成这些对象后立即清理它们。下面是我创建的一个函数，用于分配名为xlStyleHeader的Style对象的一些财产：
public Excel.Style xlStyleHeader = null;
private void CreateHeaderStyle()
{
Excel.Styles xlStyles = null;
Excel.Font xlFont = null;
Excel.Interior xlInterior = null;
Excel.Borders xlBorders = null;
Excel.Border xlBorderBottom = null;
try
{
xlStyles = xlWorkbook.Styles;
xlStyleHeader = xlStyles.Add("Header", Type.Missing);
// Text Format
xlStyleHeader.NumberFormat = "@";
// Bold
xlFont = xlStyleHeader.Font;
xlFont.Bold = true;
// Light Gray Cell Color
xlInterior = xlStyleHeader.Interior;
xlInterior.Color = 12632256;
// Medium Bottom border
xlBorders = xlStyleHeader.Borders;
xlBorderBottom = xlBorders[Excel.XlBordersIndex.xlEdgeBottom];
xlBorderBottom.Weight = Excel.XlBorderWeight.xlMedium;
}
catch (Exception ex)
{
throw ex;
}
finally
{
Release(xlBorderBottom);
Release(xlBorders);
Release(xlInterior);
Release(xlFont);
Release(xlStyles);
}
}
private void Release(object obj)
{
// Errors are ignored per Microsoft's suggestion for this type of function:
// http://support.microsoft.com/default.aspx/kb/317109
try
{
System.Runtime.InteropServices.Marshal.ReleaseComObject(obj);
}
catch { }
}
请注意，我必须将xlBorders[Excel.XlBordersIndex.xlEdgeBottom]设置为一个变量，以清除该变量（不是因为两个点，这两个点指的是不需要释放的枚举，而是因为我所指的对象实际上是一个需要释放的Border对象）。
在标准应用程序中，这种事情并不是真正必要的，因为这些应用程序在清理后会做得很好，但在ASP.NET应用程序中如果您错过了其中的一个，无论您调用垃圾收集器的频率如何，Excel仍将在您的服务器上运行。
编写这段代码时，在监视任务管理器的同时，它需要对细节和许多测试执行进行大量关注，但这样做可以省去在代码页中拼命搜索以查找遗漏的一个实例的麻烦。当在循环中工作时，这一点尤其重要，因为您需要释放对象的每个实例，即使它每次循环都使用相同的变量名。
我找到了一个有用的通用模板，它可以帮助实现COM对象的正确处置模式，这些对象在超出范围时需要调用Marshal.ReleaseComObject：
用法：
using (AutoReleaseComObject<Application> excelApplicationWrapper = new AutoReleaseComObject<Application>(new Application()))
{
try
{
using (AutoReleaseComObject<Workbook> workbookWrapper = new AutoReleaseComObject<Workbook>(excelApplicationWrapper.ComObject.Workbooks.Open(namedRangeBase.FullName, false, false, missing, missing, missing, true, missing, missing, true, missing, missing, missing, missing, missing)))
{
// do something with your workbook....
}
}
finally
{
excelApplicationWrapper.ComObject.Quit();
}
}
模板：
public class AutoReleaseComObject<T> : IDisposable
{
private T m_comObject;
private bool m_armed = true;
private bool m_disposed = false;
public AutoReleaseComObject(T comObject)
{
Debug.Assert(comObject != null);
m_comObject = comObject;
}
#if DEBUG
~AutoReleaseComObject()
{
// We should have been disposed using Dispose().
Debug.WriteLine("Finalize being called, should have been disposed");
if (this.ComObject != null)
{
Debug.WriteLine(string.Format("ComObject was not null:{0}, name:{1}.", this.ComObject, this.ComObjectName));
}
//Debug.Assert(false);
}
#endif
public T ComObject
{
get
{
Debug.Assert(!m_disposed);
return m_comObject;
}
}
private string ComObjectName
{
get
{
if(this.ComObject is Microsoft.Office.Interop.Excel.Workbook)
{
return ((Microsoft.Office.Interop.Excel.Workbook)this.ComObject).Name;
}
return null;
}
}
public void Disarm()
{
Debug.Assert(!m_disposed);
m_armed = false;
}
#region IDisposable Members
public void Dispose()
{
Dispose(true);
#if DEBUG
GC.SuppressFinalize(this);
#endif
}
#endregion
protected virtual void Dispose(bool disposing)
{
if (!m_disposed)
{
if (m_armed)
{
int refcnt = 0;
do
{
refcnt = System.Runtime.InteropServices.Marshal.ReleaseComObject(m_comObject);
} while (refcnt > 0);
m_comObject = default(T);
}
m_disposed = true;
}
}
}
参考：
http://www.deez.info/sengelha/2005/02/11/useful-idisposable-class-3-autoreleasecomobject/
拍摄Excel程序并咀嚼泡泡糖
public class MyExcelInteropClass
{
Excel.Application xlApp;
Excel.Workbook xlBook;
public void dothingswithExcel()
{
try { /* Do stuff manipulating cells sheets and workbooks ... */ }
catch {}
finally {KillExcelProcess(xlApp);}
}
static void KillExcelProcess(Excel.Application xlApp)
{
if (xlApp != null)
{
int excelProcessId = 0;
GetWindowThreadProcessId(xlApp.Hwnd, out excelProcessId);
Process p = Process.GetProcessById(excelProcessId);
p.Kill();
xlApp = null;
}
}
[DllImport("user32.dll")]
static extern int GetWindowThreadProcessId(int hWnd, out int lpdwProcessId);
}
这对我正在进行的一个项目起到了作用：
excelApp.Quit();
Marshal.ReleaseComObject (excelWB);
Marshal.ReleaseComObject (excelApp);
excelApp = null;
我们了解到，在使用Excel COM对象时，将其每个引用都设置为空非常重要。这包括单元格、工作表和所有内容。
更新：添加了C#代码，并链接到Windows作业
我花了一些时间试图解决这个问题，当时XtremeVBTalk是最活跃和响应最快的。这里有一个链接到我的原始文章，“即使应用程序崩溃，也要干净地关闭Excel互操作过程”。下面是文章的摘要，以及复制到本文的代码。
使用Application.Quit（）和process.Kill（）关闭Interop进程在很大程度上是有效的，但如果应用程序发生灾难性崩溃，则会失败。也就是说，如果应用程序崩溃，Excel进程仍将运行松散。解决方案是让操作系统使用Win32调用通过Windows作业对象处理进程的清理。当主应用程序失效时，相关的进程（即Excel）也将终止。
我发现这是一个干净的解决方案，因为操作系统正在进行真正的清理工作。您所要做的就是注册Excel进程。
Windows作业代码
包装Win32 API调用以注册互操作进程。
public enum JobObjectInfoType
{
AssociateCompletionPortInformation = 7,
BasicLimitInformation = 2,
BasicUIRestrictions = 4,
EndOfJobTimeInformation = 6,
ExtendedLimitInformation = 9,
SecurityLimitInformation = 5,
GroupInformation = 11
}
[StructLayout(LayoutKind.Sequential)]
public struct SECURITY_ATTRIBUTES
{
public int nLength;
public IntPtr lpSecurityDescriptor;
public int bInheritHandle;
}
[StructLayout(LayoutKind.Sequential)]
struct JOBOBJECT_BASIC_LIMIT_INFORMATION
{
public Int64 PerProcessUserTimeLimit;
public Int64 PerJobUserTimeLimit;
public Int16 LimitFlags;
public UInt32 MinimumWorkingSetSize;
public UInt32 MaximumWorkingSetSize;
public Int16 ActiveProcessLimit;
public Int64 Affinity;
public Int16 PriorityClass;
public Int16 SchedulingClass;
}
[StructLayout(LayoutKind.Sequential)]
struct IO_COUNTERS
{
public UInt64 ReadOperationCount;
public UInt64 WriteOperationCount;
public UInt64 OtherOperationCount;
public UInt64 ReadTransferCount;
public UInt64 WriteTransferCount;
public UInt64 OtherTransferCount;
}
[StructLayout(LayoutKind.Sequential)]
struct JOBOBJECT_EXTENDED_LIMIT_INFORMATION
{
public JOBOBJECT_BASIC_LIMIT_INFORMATION BasicLimitInformation;
public IO_COUNTERS IoInfo;
public UInt32 ProcessMemoryLimit;
public UInt32 JobMemoryLimit;
public UInt32 PeakProcessMemoryUsed;
public UInt32 PeakJobMemoryUsed;
}
public class Job : IDisposable
{
[DllImport("kernel32.dll", CharSet = CharSet.Unicode)]
static extern IntPtr CreateJobObject(object a, string lpName);
[DllImport("kernel32.dll")]
static extern bool SetInformationJobObject(IntPtr hJob, JobObjectInfoType infoType, IntPtr lpJobObjectInfo, uint cbJobObjectInfoLength);
[DllImport("kernel32.dll", SetLastError = true)]
static extern bool AssignProcessToJobObject(IntPtr job, IntPtr process);
private IntPtr m_handle;
private bool m_disposed = false;
public Job()
{
m_handle = CreateJobObject(null, null);
JOBOBJECT_BASIC_LIMIT_INFORMATION info = new JOBOBJECT_BASIC_LIMIT_INFORMATION();
info.LimitFlags = 0x2000;
JOBOBJECT_EXTENDED_LIMIT_INFORMATION extendedInfo = new JOBOBJECT_EXTENDED_LIMIT_INFORMATION();
extendedInfo.BasicLimitInformation = info;
int length = Marshal.SizeOf(typeof(JOBOBJECT_EXTENDED_LIMIT_INFORMATION));
IntPtr extendedInfoPtr = Marshal.AllocHGlobal(length);
Marshal.StructureToPtr(extendedInfo, extendedInfoPtr, false);
if (!SetInformationJobObject(m_handle, JobObjectInfoType.ExtendedLimitInformation, extendedInfoPtr, (uint)length))
throw new Exception(string.Format("Unable to set information. Error: {0}", Marshal.GetLastWin32Error()));
}
#region IDisposable Members
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
#endregion
private void Dispose(bool disposing)
{
if (m_disposed)
return;
if (disposing) {}
Close();
m_disposed = true;
}
public void Close()
{
Win32.CloseHandle(m_handle);
m_handle = IntPtr.Zero;
}
public bool AddProcess(IntPtr handle)
{
return AssignProcessToJobObject(m_handle, handle);
}
}
关于构造函数代码的注释
在构造函数中，info.LimitFlags=0x2000；被调用。0x2000是JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE枚举值，MSDN将此值定义为：
当作业的最后一个句柄关闭。
获取进程ID（PID）的额外Win32 API调用
[DllImport("user32.dll", SetLastError = true)]
public static extern uint GetWindowThreadProcessId(IntPtr hWnd, out uint lpdwProcessId);
使用代码
Excel.Application app = new Excel.ApplicationClass();
Job job = new Job();
uint pid = 0;
Win32.GetWindowThreadProcessId(new IntPtr(app.Hwnd), out pid);
job.AddProcess(Process.GetProcessById((int)pid).Handle);
