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

更新：添加了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);

Excel命名空间中的任何内容都需要发布。时期

你不能这样做：

Worksheet ws = excel.WorkBooks[1].WorkSheets[1];

你必须这样做

Workbooks books = excel.WorkBooks;
Workbook book = books[1];
Sheets sheets = book.WorkSheets;
Worksheet ws = sheets[1];

随后释放物体。

我一直遵循VVS答案中的建议。然而，为了使这个答案与最新的选项保持同步，我认为我未来的所有项目都将使用“NetOffice”库。

NetOffice是Office PIA的完全替代品，完全不受版本限制。它是一个托管COM包装器的集合，可以处理在.NET中使用Microsoft Office时经常引起此类麻烦的清理。

一些关键功能包括：

大部分与版本无关（记录了与版本相关的功能）无相关性无PIA没有注册无VSTO

我与该项目毫无关联；我真的很欣赏头痛的明显减轻。

到目前为止，似乎所有的答案都涉及其中一些：

终止进程使用GC.Collect（）跟踪每个COM对象并正确释放它。

这让我意识到这个问题有多么困难：）

我一直在开发一个库来简化对Excel的访问，我正在努力确保使用它的人不会留下一片混乱（手指交叉）。

我没有直接在Interop提供的接口上进行编写，而是使用扩展方法来简化工作。类似于ApplicationHelpers.CreateExcel（）或工作簿.CreateWorksheet（“mySheetNameThatWillBeValidated”）。自然，任何创建的东西都可能会在以后的清理中导致问题，所以我实际上更倾向于在最后的手段中终止这个过程。然而，正确清理（第三种选择）可能是破坏性最小、控制性最强的。

因此，在这种情况下，我想知道这样做是否不是最好的：

public abstract class ReleaseContainer<T>
{
    private readonly Action<T> actionOnT;

    protected ReleaseContainer(T releasible, Action<T> actionOnT)
    {
        this.actionOnT = actionOnT;
        this.Releasible = releasible;
    }

    ~ReleaseContainer()
    {
        Release();
    }

    public T Releasible { get; private set; }

    private void Release()
    {
        actionOnT(Releasible);
        Releasible = default(T);
    }
}

我用“不可行”来避免与一次性使用混淆。但将其扩展到IDisposable应该很容易。

这样的实现：

public class ApplicationContainer : ReleaseContainer<Application>
{
    public ApplicationContainer()
        : base(new Application(), ActionOnExcel)
    {
    }

    private static void ActionOnExcel(Application application)
    {
        application.Show(); // extension method. want to make sure the app is visible.
        application.Quit();
        Marshal.FinalReleaseComObject(application);
    }
}

可以对所有类型的COM对象执行类似的操作。

在工厂方法中：

    public static Application CreateExcelApplication(bool hidden = false)
    {
        var excel = new ApplicationContainer().Releasible;
        excel.Visible = !hidden;

        return excel;
    }

我希望每个容器都会被GC正确地销毁，因此会自动调用Quit和Marshal.FinalReleaseComObject。

评论？或者这是对第三类问题的回答？

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