我在C#(ApplicationClass)中使用Excel互操作,并在finally子句中放置了以下代码:

while (System.Runtime.InteropServices.Marshal.ReleaseComObject(excelSheet) != 0) { }
excelSheet = null;
GC.Collect();
GC.WaitForPendingFinalizers();

尽管这种方法有效,但即使在我关闭Excel之后,Excel.exe进程仍处于后台。它只在我的应用程序被手动关闭后发布。

我做错了什么,或者是否有其他方法可以确保正确处理互操作对象?


当前回答

两点规则不适用于我。在我的案例中,我创建了一种方法来清理我的资源,如下所示:

private static void Clean()
{
    workBook.Close();
    Marshall.ReleaseComObject(workBook);
    excel.Quit();
    CG.Collect();
    CG.WaitForPendingFinalizers();
}

其他回答

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实例,有不同的方法和建议,例如:

显式释放EVERY com对象使用Marshal.FinalReleaseComObject()(不忘含蓄创建的com对象)。释放每个创建的com对象,您可以使用这里提到的2点规则:如何正确清理Excel互操作对象?调用GC.Collect()和GC.WaitForPendingFinalizers()生成CLR释放未使用的com对象*(实际上,它是有效的,有关详细信息,请参阅我的第二个解决方案)检查com服务器应用程序可能会显示一个等待的消息框用户回答(尽管我不是确保它可以阻止Excel结束了,但我听说过几次次)向主服务器发送WM_CLOSE消息Excel窗口执行有效的函数在单独的AppDomain中使用Excel。有些人相信Excel实例当AppDomain为卸载。终止在excel互操作代码启动后实例化的所有excel实例。

但是!有时所有这些选项都没有帮助或不合适!

例如,昨天我发现在我的一个函数(与excel一起工作)中,excel在函数结束后仍在运行。我什么都试过了!我彻底检查了整个函数10次,并为所有内容添加了Marshal.FinalReleaseComObject()!我还有GC.Collect()和GC.WaitForPendingFinalizers()。我检查了隐藏的消息框。我试图将WM_CLOSE消息发送到Excel主窗口。我在一个单独的AppDomain中执行了我的函数,并卸载了该域。没什么帮助!关闭所有excel实例的选项是不合适的,因为如果用户在执行我的函数(该函数也适用于excel)期间手动启动另一个excel实例,则该实例也将被我的函数关闭。我打赌用户不会高兴的!所以,老实说,这是一个蹩脚的选择(没有冒犯的家伙)。所以我花了几个小时才找到了一个好的(我个人认为)解决方案:通过关闭excel进程的主窗口(这是第一个解决方案)。

下面是简单的代码:

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

/// <summary> Tries to find and kill process by hWnd to the main window of the process.</summary>
/// <param name="hWnd">Handle to the main window of the process.</param>
/// <returns>True if process was found and killed. False if process was not found by hWnd or if it could not be killed.</returns>
public static bool TryKillProcessByMainWindowHwnd(int hWnd)
{
    uint processID;
    GetWindowThreadProcessId((IntPtr)hWnd, out processID);
    if(processID == 0) return false;
    try
    {
        Process.GetProcessById((int)processID).Kill();
    }
    catch (ArgumentException)
    {
        return false;
    }
    catch (Win32Exception)
    {
        return false;
    }
    catch (NotSupportedException)
    {
        return false;
    }
    catch (InvalidOperationException)
    {
        return false;
    }
    return true;
}

/// <summary> Finds and kills process by hWnd to the main window of the process.</summary>
/// <param name="hWnd">Handle to the main window of the process.</param>
/// <exception cref="ArgumentException">
/// Thrown when process is not found by the hWnd parameter (the process is not running). 
/// The identifier of the process might be expired.
/// </exception>
/// <exception cref="Win32Exception">See Process.Kill() exceptions documentation.</exception>
/// <exception cref="NotSupportedException">See Process.Kill() exceptions documentation.</exception>
/// <exception cref="InvalidOperationException">See Process.Kill() exceptions documentation.</exception>
public static void KillProcessByMainWindowHwnd(int hWnd)
{
    uint processID;
    GetWindowThreadProcessId((IntPtr)hWnd, out processID);
    if (processID == 0)
        throw new ArgumentException("Process has not been found by the given main window handle.", "hWnd");
    Process.GetProcessById((int)processID).Kill();
}

正如您所看到的,根据Try Parse模式,我提供了两种方法(我认为这在这里是合适的):一种方法在无法终止进程时不会抛出异常(例如,进程不再存在),另一种方法则在进程未终止时抛出异常。此代码中唯一的弱点是安全权限。理论上,用户可能没有权限终止进程,但在所有情况下,99.99%的用户都有这样的权限。我还用一个客户帐户测试了它-它工作得很好。

因此,使用Excel的代码可以如下所示:

int hWnd = xl.Application.Hwnd;
// ...
// here we try to close Excel as usual, with xl.Quit(),
// Marshal.FinalReleaseComObject(xl) and so on
// ...
TryKillProcessByMainWindowHwnd(hWnd);

瞧!Excel已终止!:)

好的,让我们回到第二个解决方案,正如我在文章开头所承诺的那样。第二种解决方案是调用GC.Collect()和GC.WaitForPendingFinalizers()。是的,它们确实有效,但这里需要小心!很多人说(我也说过)调用GC.Collect()没有帮助。但是,如果仍然有对COM对象的引用,这将毫无帮助!GC.Collect()不起作用的最常见原因之一是以调试模式运行项目。在调试模式下,在方法结束之前,不再真正引用的对象不会被垃圾收集。因此,如果您尝试了GC.Collect()和GC.WaitForPendingFinalizers(),但没有帮助,请尝试执行以下操作:

1) 尝试在发布模式下运行项目,并检查Excel是否正确关闭

2) 将使用Excel的方法包装在单独的方法中。所以,不要像这样:

void GenerateWorkbook(...)
{
  ApplicationClass xl;
  Workbook xlWB;
  try
  {
    xl = ...
    xlWB = xl.Workbooks.Add(...);
    ...
  }
  finally
  {
    ...
    Marshal.ReleaseComObject(xlWB)
    ...
    GC.Collect();
    GC.WaitForPendingFinalizers();
  }
}

你写道:

void GenerateWorkbook(...)
{
  try
  {
    GenerateWorkbookInternal(...);
  }
  finally
  {
    GC.Collect();
    GC.WaitForPendingFinalizers();
  }
}

private void GenerateWorkbookInternal(...)
{
  ApplicationClass xl;
  Workbook xlWB;
  try
  {
    xl = ...
    xlWB = xl.Workbooks.Add(...);
    ...
  }
  finally
  {
    ...
    Marshal.ReleaseComObject(xlWB)
    ...
  }
}

现在,Excel将关闭=)

当上面的所有内容都不起作用时,请尝试给Excel一些时间来关闭工作表:

app.workbooks.Close();
Thread.Sleep(500); // adjust, for me it works at around 300+
app.Quit();

...
FinalReleaseComObject(app);

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

我认为其中一些只是框架处理Office应用程序的方式,但我可能错了。在某些日子,一些应用程序会立即清理进程,而在其他日子,似乎要等到应用程序关闭。总的来说,我不再关注细节,只是确保一天结束时没有任何额外的流程。

还有,也许我过于简化了,但我想你可以。。。

objExcel = new Excel.Application();
objBook = (Excel.Workbook)(objExcel.Workbooks.Add(Type.Missing));
DoSomeStuff(objBook);
SaveTheBook(objBook);
objBook.Close(false, Type.Missing, Type.Missing);
objExcel.Quit();

正如我之前所说,我不太关注Excel进程出现或消失的细节,但这通常对我有用。我也不喜欢在最短的时间内保持Excel进程,但我可能只是在这方面有点偏执。