首先，在执行Excel互操作时，您永远不必调用Marshal.ReleaseComObject（…）或Marshal.FinalReleaseComObject（.）。这是一个令人困惑的反模式，但任何有关此的信息（包括来自Microsoft的信息）都是不正确的，这些信息表明您必须从.NET手动释放COM引用。事实上，.NET运行时和垃圾收集器正确地跟踪和清理COM引用。对于您的代码，这意味着您可以删除顶部的整个`while（…）循环。

其次，如果要确保在进程结束时清理进程外COM对象的COM引用（以便Excel进程关闭），则需要确保垃圾收集器运行。您可以通过调用GC.Collect（）和GC.WaitForPendingFinalizers（）来正确地执行此操作。两次调用此操作是安全的，并且可以确保周期也被彻底清理（尽管我不确定是否需要，我希望能有一个示例来说明这一点）。

第三，当在调试器下运行时，本地引用将被人为地保持活动状态，直到方法结束（以便本地变量检查工作）。因此，GC.Collect（）调用对于从同一方法中清除rng.Cells等对象无效。您应该将执行GC清理中的COM互操作的代码拆分为单独的方法。（这是我的一个关键发现，来自@nightcoder在这里发布的答案的一部分。）

因此，一般模式为：

Sub WrapperThatCleansUp()

    ' NOTE: Don't call Excel objects in here... 
    '       Debugger would keep alive until end, preventing GC cleanup

    ' Call a separate function that talks to Excel
    DoTheWork()

    ' Now let the GC clean up (twice, to clean up cycles too)
    GC.Collect()    
    GC.WaitForPendingFinalizers()
    GC.Collect()    
    GC.WaitForPendingFinalizers()

End Sub

Sub DoTheWork()
    Dim app As New Microsoft.Office.Interop.Excel.Application
    Dim book As Microsoft.Office.Interop.Excel.Workbook = app.Workbooks.Add()
    Dim worksheet As Microsoft.Office.Interop.Excel.Worksheet = book.Worksheets("Sheet1")
    app.Visible = True
    For i As Integer = 1 To 10
        worksheet.Cells.Range("A" & i).Value = "Hello"
    Next
    book.Save()
    book.Close()
    app.Quit()

    ' NOTE: No calls the Marshal.ReleaseComObject() are ever needed
End Sub

关于这个问题有很多虚假信息和困惑，包括MSDN和Stack Overflow上的许多帖子（尤其是这个问题！）。

最终说服我仔细研究并找出正确建议的是博客文章Marshal.ReleaseComObject Considered Dangerous，以及发现在调试器下引用保持活动的问题，这让我之前的测试感到困惑。

使用Microsoft Excel 2016测试

一个真正经过测试的解决方案。

参考C#，请参见：https://stackoverflow.com/a/1307180/10442623

VB.net参考请参见：https://stackoverflow.com/a/54044646/10442623

1包括课堂作业

2实现该类以处理excel进程的适当处理

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互操作对象

这里有一个非常简单的方法：

[DllImport("User32.dll")]
static extern uint GetWindowThreadProcessId(IntPtr hWnd, out int lpdwProcessId);
...

int objExcelProcessId = 0;

Excel.Application objExcel = new Excel.Application();

GetWindowThreadProcessId(new IntPtr(objExcel.Hwnd), out objExcelProcessId);

Process.GetProcessById(objExcelProcessId).Kill();

正如一些人可能已经写过的，如何关闭Excel（对象）不仅重要；如何打开它以及项目类型也很重要。

在WPF应用程序中，基本上相同的代码在没有或很少有问题的情况下工作。

我有一个项目，在该项目中，同一个Excel文件针对不同的参数值被处理了多次-例如，基于通用列表中的值对其进行分析。

我将所有与Excel相关的函数放在基类中，将解析器放在一个子类中（不同的解析器使用通用的Excel函数）。我不希望Excel为泛型列表中的每个项再次打开和关闭，所以我只在基类中打开了一次，并在子类中关闭了它。我在将代码移动到桌面应用程序时遇到了问题。我已经尝试了上面提到的许多解决方案。以前已经实现了GC.Collect（），是建议的两倍。

然后我决定将打开Excel的代码移到一个子类中。现在我不再只打开一次，而是创建一个新对象（基类），为每个项目打开Excel并在最后关闭它。有一些性能损失，但根据几个测试，Excel进程关闭时没有问题（在调试模式下），因此临时文件也会被删除。如果我能得到一些更新，我会继续测试并写更多。

底线是：您还必须检查初始化代码，特别是如果您有许多类等。

这看起来确实太复杂了。根据我的经验，要让Excel正确关闭，只有三件关键的事情：

1：确保没有对您创建的excel应用程序的剩余引用（无论如何，您应该只有一个引用；将其设置为空）

2：调用GC.Collect（）

3:必须通过用户手动关闭程序或通过对Excel对象调用“退出”来关闭Excel。（请注意，“退出”的功能与用户试图关闭程序的功能相同，如果存在未保存的更改，即使Excel不可见，也会显示一个确认对话框。用户可以按“取消”，Excel将不会关闭。）

1需要在2之前发生，但3可以随时发生。

实现这一点的一种方法是用自己的类包装interop Excel对象，在构造函数中创建interop实例，并使用Dispose实现IDisposable

这将从程序的方面清理出优秀的东西。一旦Excel关闭（由用户手动或您调用退出），该过程将消失。如果程序已经关闭，那么进程将在GC.Collect（）调用中消失。

（我不确定它有多重要，但您可能需要在GC.Collect（）调用之后调用GC.WaitForPendingFinalizers（），但这并不是完全需要摆脱Excel进程。）

多年来，这对我来说毫无问题。请记住，虽然这是有效的，但实际上您必须优雅地关闭它才能工作。如果在清理excel之前中断程序（通常在调试程序时单击“停止”），则仍会累积excel.exe进程