我在C#（ApplicationClass）中使用Excel互操作，并在finally子句中放置了以下代码：
while (System.Runtime.InteropServices.Marshal.ReleaseComObject(excelSheet) != 0) { }
excelSheet = null;
GC.Collect();
GC.WaitForPendingFinalizers();
尽管这种方法有效，但即使在我关闭Excel之后，Excel.exe进程仍处于后台。它只在我的应用程序被手动关闭后发布。
我做错了什么，或者是否有其他方法可以确保正确处理互操作对象？
当前回答
正如其他人所指出的，您需要为使用的每个Excel对象创建一个显式引用，并对该引用调用Marshal.ReleaseComObject，如本知识库文章所述。您还需要使用try/finally来确保始终调用ReleaseComObject，即使抛出异常也是如此。即，代替：
Worksheet sheet = excelApp.Worksheets(1)
... do something with sheet
你需要做一些事情，比如：
Worksheets sheets = null;
Worksheet sheet = null
try
{
sheets = excelApp.Worksheets;
sheet = sheets(1);
...
}
finally
{
if (sheets != null) Marshal.ReleaseComObject(sheets);
if (sheet != null) Marshal.ReleaseComObject(sheet);
}
如果要关闭Excel，还需要在释放Application对象之前调用Application.Quit。
正如您所看到的，只要您尝试做任何稍微复杂的事情，这很快就会变得非常笨拙。我用一个简单的包装类成功地开发了.NET应用程序，该类包装了Excel对象模型的一些简单操作（打开工作簿、写入范围、保存/关闭工作簿等）。包装器类实现IDisposable，在它使用的每个对象上仔细地实现Marshal.ReleaseComObject，并且不向应用程序的其他部分公开任何Excel对象。
但这种方法不能很好地适应更复杂的需求。
这是.NETCOM互操作的一大缺陷。对于更复杂的场景，我会认真考虑用VB6或其他非托管语言编写ActiveX DLL，您可以将与进程外COM对象（如Office）的所有交互委托给它。然后，您可以从.NET应用程序中引用此ActiveX DLL，因为您只需要发布这一个引用，所以事情会变得更加简单。
其他回答
我找到了一个有用的通用模板，它可以帮助实现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/
更新：添加了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);
我不敢相信这个问题已经困扰了世界五年。。。。如果您已经创建了应用程序，则需要在删除链接之前先关闭它。
objExcel = new Excel.Application();
objBook = (Excel.Workbook)(objExcel.Workbooks.Add(Type.Missing));
关闭时
objBook.Close(true, Type.Missing, Type.Missing);
objExcel.Application.Quit();
objExcel.Quit();
当您新建一个excel应用程序时，它会在后台打开一个excel程序。您需要在释放链接之前命令该excel程序退出，因为该excel程序不是您直接控制的一部分。因此，如果链接被释放，它将保持开放！
每个人都很好编程~~
Excel并非设计为通过C++或C#编程。COM API专门设计用于Visual Basic、VB.NET和VBA。
此外，此页上的所有代码示例都不是最佳的，原因很简单，即每个调用都必须跨越托管/非托管边界，并且还忽略了这样一个事实，即Excel COM API可以自由地使任何调用失败，并带有一个神秘的HRESULT，表示RPC服务器正忙。
我认为自动化Excel的最佳方法是将数据收集到尽可能大的数组中，并将其发送到VBA函数或子函数（通过Application.Run），然后执行任何所需的处理。此外，在调用Application.Run时，请确保注意excel正忙的异常，然后重试调用Application.Run。
正如其他人所指出的，您需要为使用的每个Excel对象创建一个显式引用，并对该引用调用Marshal.ReleaseComObject，如本知识库文章所述。您还需要使用try/finally来确保始终调用ReleaseComObject，即使抛出异常也是如此。即，代替：
Worksheet sheet = excelApp.Worksheets(1)
... do something with sheet
你需要做一些事情，比如：
Worksheets sheets = null;
Worksheet sheet = null
try
{
sheets = excelApp.Worksheets;
sheet = sheets(1);
...
}
finally
{
if (sheets != null) Marshal.ReleaseComObject(sheets);
if (sheet != null) Marshal.ReleaseComObject(sheet);
}
如果要关闭Excel，还需要在释放Application对象之前调用Application.Quit。
正如您所看到的，只要您尝试做任何稍微复杂的事情，这很快就会变得非常笨拙。我用一个简单的包装类成功地开发了.NET应用程序，该类包装了Excel对象模型的一些简单操作（打开工作簿、写入范围、保存/关闭工作簿等）。包装器类实现IDisposable，在它使用的每个对象上仔细地实现Marshal.ReleaseComObject，并且不向应用程序的其他部分公开任何Excel对象。
但这种方法不能很好地适应更复杂的需求。
这是.NETCOM互操作的一大缺陷。对于更复杂的场景，我会认真考虑用VB6或其他非托管语言编写ActiveX DLL，您可以将与进程外COM对象（如Office）的所有交互委托给它。然后，您可以从.NET应用程序中引用此ActiveX DLL，因为您只需要发布这一个引用，所以事情会变得更加简单。
