实际上，您可以干净地释放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#时完全相同。

这对我正在进行的一个项目起到了作用：

excelApp.Quit();
Marshal.ReleaseComObject (excelWB);
Marshal.ReleaseComObject (excelApp);
excelApp = null;

我们了解到，在使用Excel COM对象时，将其每个引用都设置为空非常重要。这包括单元格、工作表和所有内容。

尝试之后

按相反顺序释放COM对象在末尾添加两次GC.Collect（）和GC.WaitForPendingFinalizers（）不超过两个点关闭工作簿并退出应用程序以释放模式运行

对我有效的最终解决方案是移动一组

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

我们将其添加到包装器的函数末尾，如下所示：

private void FunctionWrapper(string sourcePath, string targetPath)
{
    try
    {
        FunctionThatCallsExcel(sourcePath, targetPath);
    }
    finally
    {
        GC.Collect();
        GC.WaitForPendingFinalizers();
    }
}

Excel不会退出，因为应用程序仍保留对COM对象的引用。

我猜您调用了COM对象的至少一个成员，而没有将其分配给变量。

对我来说，它是excelApp.Worksheets对象，我直接使用它，而没有将它分配给变量：

Worksheet sheet = excelApp.Worksheets.Open(...);
...
Marshal.ReleaseComObject(sheet);

我不知道C#在内部为WorksheetsCOM对象创建了一个包装器，但我的代码没有发布它（因为我不知道），这也是Excel没有卸载的原因。

我在这个页面上找到了我的问题的解决方案，它也有一个关于C#中COM对象用法的好规则：

切勿对COM对象使用两点。

因此，有了这些知识，正确的方法是：

Worksheets sheets = excelApp.Worksheets; // <-- The important part
Worksheet sheet = sheets.Open(...);
...
Marshal.ReleaseComObject(sheets);
Marshal.ReleaseComObject(sheet);

尸检后更新：

我希望每一位读者都能非常仔细地阅读Hans Passant的回答，因为它解释了我和许多其他开发人员偶然遇到的陷阱。几年前我写这个答案时，我不知道调试器对垃圾收集器的影响，得出了错误的结论。为了历史起见，我的答案保持不变，但请阅读此链接，不要走“两点”的道路：了解.NET中的垃圾收集和使用IDisposable清理Excel互操作对象

确保释放所有与Excel相关的对象！

我花了几个小时尝试了几种方法。所有这些都是好主意，但我终于发现了我的错误：如果你不释放所有对象，上面的任何方法都不能像我这样帮助你。确保释放所有对象，包括范围1！

Excel.Range rng = (Excel.Range)worksheet.Cells[1, 1];
worksheet.Paste(rng, false);
releaseObject(rng);

这里有各种选项。

“千万不要在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接口。