我在C#（ApplicationClass）中使用Excel互操作，并在finally子句中放置了以下代码：
while (System.Runtime.InteropServices.Marshal.ReleaseComObject(excelSheet) != 0) { }
excelSheet = null;
GC.Collect();
GC.WaitForPendingFinalizers();
尽管这种方法有效，但即使在我关闭Excel之后，Excel.exe进程仍处于后台。它只在我的应用程序被手动关闭后发布。
我做错了什么，或者是否有其他方法可以确保正确处理互操作对象？
当前回答
实际上，您可以干净地释放Excel应用程序对象，但您必须小心。
建议为您访问的每个COM对象维护一个命名引用，然后通过Marshal.FinalReleaseComObject（）显式释放它，这在理论上是正确的，但不幸的是，在实践中很难管理。如果有人在任何地方滑动并使用“两点”，或者通过for each循环或任何其他类似类型的命令来迭代单元格，那么您将拥有未引用的COM对象并面临挂起的风险。在这种情况下，将无法在代码中找到原因；您必须仔细检查所有代码，并希望找到原因，这对于一个大型项目来说几乎是不可能的。
好消息是，实际上不必维护对所使用的每个COM对象的命名变量引用。相反，先调用GC.Collect（），然后调用GC.WaitForPendingFinalizers（），释放所有未持有引用的对象（通常是次要的），然后显式释放持有命名变量引用的对象。
您还应该按照相反的重要性顺序释放命名引用：首先是范围对象，然后是工作表、工作簿，最后是Excel应用程序对象。
例如，假设您有一个名为xlRng的Range对象变量、一个名名为xlSheet的工作表变量、名为xlBook的工作簿变量和名为xlApp的Excel应用程序变量，则清理代码可能如下所示：
// Cleanup
GC.Collect();
GC.WaitForPendingFinalizers();
Marshal.FinalReleaseComObject(xlRng);
Marshal.FinalReleaseComObject(xlSheet);
xlBook.Close(Type.Missing, Type.Missing, Type.Missing);
Marshal.FinalReleaseComObject(xlBook);
xlApp.Quit();
Marshal.FinalReleaseComObject(xlApp);
在大多数从.NET清理COM对象的代码示例中，GC.Collect（）和GC.WaitForPendingFinalizers（）调用两次，如下所示：
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();
但是，除非您使用的是Visual Studio Tools for Office（VSTO），该工具使用的终结器会导致整个对象图在终结队列中升级，否则这不应该是必需的。在下一次垃圾收集之前，不会释放此类对象。但是，如果您不使用VSTO，则应该能够调用GC.Collect（）和GC.WaitForPendingFinalizers（）一次。
我知道显式调用GC.Collect（）是一个不允许的做法（当然，重复两次听起来很痛苦），但老实说，没有办法解决这个问题。通过正常操作，您将生成隐藏对象，这些对象没有引用，因此，除了调用GC.Collect（）之外，您无法通过任何其他方式释放这些对象。
这是一个复杂的主题，但这确实是它的全部内容。一旦为清理过程建立了这个模板，您就可以正常编码，而不需要包装器等：-）
我在这里有一个教程：
用VB.Net／COM Interop实现Office程序的自动化
它是为VB.NET编写的，但不要因此而延迟，其原理与使用C#时完全相同。
其他回答
使用Word/Excel互操作应用程序时应该非常小心。在尝试了所有解决方案之后，我们仍然有很多“WinWord”进程在服务器上打开（有2000多个用户）。
在解决这个问题几个小时后，我意识到，如果我在不同的线程上同时使用Word.ApplicationClass.Document.open（）打开多个文档，IIS工作进程（w3wp.exe）就会崩溃，所有WinWord进程都会打开！
因此，我想这个问题没有绝对的解决方案，而是改用其他方法，如OfficeOpenXML开发。
实际上，您可以干净地释放Excel应用程序对象，但您必须小心。
建议为您访问的每个COM对象维护一个命名引用，然后通过Marshal.FinalReleaseComObject（）显式释放它，这在理论上是正确的，但不幸的是，在实践中很难管理。如果有人在任何地方滑动并使用“两点”，或者通过for each循环或任何其他类似类型的命令来迭代单元格，那么您将拥有未引用的COM对象并面临挂起的风险。在这种情况下，将无法在代码中找到原因；您必须仔细检查所有代码，并希望找到原因，这对于一个大型项目来说几乎是不可能的。
好消息是，实际上不必维护对所使用的每个COM对象的命名变量引用。相反，先调用GC.Collect（），然后调用GC.WaitForPendingFinalizers（），释放所有未持有引用的对象（通常是次要的），然后显式释放持有命名变量引用的对象。
您还应该按照相反的重要性顺序释放命名引用：首先是范围对象，然后是工作表、工作簿，最后是Excel应用程序对象。
例如，假设您有一个名为xlRng的Range对象变量、一个名名为xlSheet的工作表变量、名为xlBook的工作簿变量和名为xlApp的Excel应用程序变量，则清理代码可能如下所示：
// Cleanup
GC.Collect();
GC.WaitForPendingFinalizers();
Marshal.FinalReleaseComObject(xlRng);
Marshal.FinalReleaseComObject(xlSheet);
xlBook.Close(Type.Missing, Type.Missing, Type.Missing);
Marshal.FinalReleaseComObject(xlBook);
xlApp.Quit();
Marshal.FinalReleaseComObject(xlApp);
在大多数从.NET清理COM对象的代码示例中，GC.Collect（）和GC.WaitForPendingFinalizers（）调用两次，如下所示：
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();
但是，除非您使用的是Visual Studio Tools for Office（VSTO），该工具使用的终结器会导致整个对象图在终结队列中升级，否则这不应该是必需的。在下一次垃圾收集之前，不会释放此类对象。但是，如果您不使用VSTO，则应该能够调用GC.Collect（）和GC.WaitForPendingFinalizers（）一次。
我知道显式调用GC.Collect（）是一个不允许的做法（当然，重复两次听起来很痛苦），但老实说，没有办法解决这个问题。通过正常操作，您将生成隐藏对象，这些对象没有引用，因此，除了调用GC.Collect（）之外，您无法通过任何其他方式释放这些对象。
这是一个复杂的主题，但这确实是它的全部内容。一旦为清理过程建立了这个模板，您就可以正常编码，而不需要包装器等：-）
我在这里有一个教程：
用VB.Net／COM Interop实现Office程序的自动化
它是为VB.NET编写的，但不要因此而延迟，其原理与使用C#时完全相同。
您需要意识到Excel对您正在运行的文化也非常敏感。
您可能会发现，在调用Excel函数之前，需要将区域性设置为EN-US。这并不适用于所有函数，但适用于其中一些函数。
CultureInfo en_US = new System.Globalization.CultureInfo("en-US");
System.Threading.Thread.CurrentThread.CurrentCulture = en_US;
string filePathLocal = _applicationObject.ActiveWorkbook.Path;
System.Threading.Thread.CurrentThread.CurrentCulture = orgCulture;
即使您正在使用VSTO，这也适用。
有关详细信息：http://support.microsoft.com/default.aspx?scid=kb;我们；第320369季度
这里公认的答案是正确的，但也要注意，不仅需要避免“双点”引用，还需要避免通过索引检索的对象。您也不需要等到程序完成后才能清理这些对象，最好创建函数，以便在可能的情况下，在完成这些对象后立即清理它们。下面是我创建的一个函数，用于分配名为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/
