我怎么正确地清理Excel互操作的对象?
-
03-07-2019 - |
题
我是使用Excel的互操作C#(ApplicationClass
)和安置以下代码在我的最后条款:
while (System.Runtime.InteropServices.Marshal.ReleaseComObject(excelSheet) != 0) { }
excelSheet = null;
GC.Collect();
GC.WaitForPendingFinalizers();
虽然这种工作, Excel.exe
过程仍然是在该背景甚至后我闭Excel。这是只公布一次我用的是手动关闭。
我在做什么错误的,或者是否有替代,以确保互操作的对象是正确的布置的?
解决方案
Excel不会退出,因为您的应用程序仍然保持对COM对象的引用。
我猜你是在调用COM对象的至少一个成员而不将其分配给变量。
对我来说,我直接使用 excelApp.Worksheets 对象而不将其分配给变量:
Worksheet sheet = excelApp.Worksheets.Open(...);
...
Marshal.ReleaseComObject(sheet);
我不知道内部C#为工作表 COM对象创建了一个包装器,它没有被我的代码释放(因为我不知道它),这就是为什么Excel没有卸载。
其他提示
您可以干净利落地发布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对象,<=>和<=>调用是TWICE,如下所示:
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();
但是,除非您使用的是Visual Studio Tools for Office(VSTO),否则不需要这样做,因为它使用终结器来导致在终结队列中提升整个对象图。在 next 垃圾收集之前,这些对象不会被释放。但是,如果您不使用VSTO,则应该只能拨打<=>和<=>一次。
我知道明确地调用<=>是一个禁忌(当然这两次听起来非常痛苦),但说实话,没有办法解决它。通过正常操作,您将生成隐藏的对象,您不会引用该引用,因此除了调用<=>之外,您无法通过任何其他方式释放。
这是一个复杂的话题,但这就是它的全部内容。为清理过程建立此模板后,您可以正常编码,无需包装等。: - )
我在这里有一个教程:
使用VB.Net / COM Interop自动化Office程序
它是为VB.NET编写的,但不要因此而被推迟,其原理与使用C#时完全相同。
前言:我的答案包含两个解决方案,因此应谨慎阅读时的和不错过任何东西。
有不同的方式,并建议如何使Excel实例卸载,例如:
释放每一个com对象明确 与元帅。FinalReleaseComObject() (不要忘记约含蓄地 创建com的对象)。释放 每个创造com目的,你可以使用 该规则的2点提到:
我怎么正确地清理Excel互操作的对象?叫GC。收集()及 GC。WaitForPendingFinalizers()使 CLR释放未使用com的对象*(实际上,它的工作,请参阅我的第二个解决方案的细节)
检查如果com-服务器的应用 也许显示出一个信息框在等待 用户回答(虽然我不是 肯定可以防止Excel 关闭的,但我听说了一些 次)
发送WM_CLOSE的主要消息 Excel的窗口
执行功能工作 与在一个单独的程序域.有些人认为Excel实例 将被关闭,当域是 卸载。
杀死所有的excel例实例之后,我们的excel interoping码开始。
但是! 有时候,所有这些选项只是不帮助或者不可能是合适!
例如,昨天我发现在我的功能(这适用excel)Excel保持运行之后功能结束。我尝试了一切!我彻底地检查整个函数的10倍,并加元帅。FinalReleaseComObject()对于一切!我还有GC。收集()and GC。WaitForPendingFinalizers().我检查隐藏的邮箱。我试图发送WM_CLOSE消息的主要Excel窗口。我执行我的功能在一个单独的程序域和卸载那域。没有什么帮助!选择有关的所有excel实例是不适当的,因为如果用户开始另一个Excel实例手动,在执行期间的我的功能,其运作也与Excel,那么这一实例也将关闭我的功能。我敢打赌,用户不会高兴!因此,老实说,这是一个跛脚的备选办法(没有犯罪的人).所以我花了几个小时前我发现了一个良好(以我谦卑的意见) 解决方案: 杀excel过程中通过hWnd其主窗口 (这是第一个解决方案)。
这里是简单的代码:
[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();
}
正如你可以看到我提供两种方法,根据试试-分析模式(我认为这是适当的):一个方法并不把异常,如果进程不可能是杀害(例如过程已不存在),而另一个方法引发的异常,如果进程不是杀害。唯一的弱的地方在这个码的安全权限。从理论上说,用户可能无权杀死的过程,但在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。收集()and GC。WaitForPendingFinalizers(). 是的,他们实际工作,但你必须小心,这里!
许多人说的(我所述),呼吁GC。收集()不帮助。但原因也不会帮助就是如果仍然引用COM对象!最受欢迎的一个原因GC。收集()不是有帮助的是运行的项目在调试的模式。在调试模式对象,是不是真的引用了不会的垃圾收集,直到结束的方法。
所以,如果你尝试过的GC。收集()and GC。WaitForPendingFinalizers()并没有帮助,尽量做到如下:
1)试运行中的项目释放模式和检查,如果Excel正确关闭
2)包装方法的工作与在一个单独的方法。因此,而不是像这样的东西:
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将近=)
更新:加入C#码,并链接到Windows工作
我花了某个时候试图找出这个问题,并在时间XtremeVBTalk是最活跃和敏感。这里是一个链接到我原来的岗位, 闭Excel互操作过程顺利,即使应用程序的崩溃.下面是一个摘要后,代码复制到这个职位。
- 关闭的互操作过程
Application.Quit()
和Process.Kill()
工作大部分,但是失败如果应用程序崩溃的灾难性的。I.e。如果应用程序崩溃,Excel进程将仍然运行的宽松。 - 该方案是要让OS处理的清理你的流程 Windows工作的对象 使用Win32话。当你的主要应用程序的死亡,相关的进程(即Excel)将得到终止。
我发现这是一个干净的解决方案,因为该系统做实际工作的清洁。你所要做的就是 注册 Excel的过程。
Windows工作的代码
包裹Win32API电话注册的互操作流程。
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 为:
导致所有进程相关的工作,以终止当 最后处理作业的关闭。
额外的Win32API呼吁得到的过程ID(PID)
[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);
这适用于我正在进行的项目:
excelApp.Quit();
Marshal.ReleaseComObject (excelWB);
Marshal.ReleaseComObject (excelApp);
excelApp = null;
我们了解到,当您完成Excel COM对象的每个引用时,将其设置为null非常重要。这包括细胞,表格和一切。
需要释放Excel命名空间中的任何内容。期间强>
你无法做到:
Worksheet ws = excel.WorkBooks[1].WorkSheets[1];
你必须要做
Workbooks books = excel.WorkBooks;
Workbook book = books[1];
Sheets sheets = book.WorkSheets;
Worksheet ws = sheets[1];
然后释放物体。
首先 - 在执行Excel互操作时,从不必须调用Marshal.ReleaseComObject(...)
或Marshal.FinalReleaseComObject(...)
。这是一个令人困惑的反模式,但是有关此的任何信息,包括来自Microsoft,表明您必须从.NET手动释放COM引用的任何信息都是不正确的。事实是.NET运行时和垃圾收集器正确地跟踪和清理COM引用。对于你的代码,这意味着你可以删除顶部的整个`while(...)循环。
其次,如果要确保在进程结束时清除对进程外COM对象的COM引用(以便Excel进程关闭),则需要确保垃圾收集器运行。您可以通过调用GC.Collect()
和GC.WaitForPendingFinalizers()
来正确执行此操作。调用这两次是安全的,并确保周期也被清理干净(虽然我不确定它是否需要,并且会欣赏一个显示这一点的例子。)
第三,当在调试器下运行时,本地引用将被人为地保持活动直到方法结束(以便局部变量检查起作用)。因此,rng.Cells
调用对于从同一方法清除<=>等对象无效。您应该将执行COM interop的代码从GC清理拆分为单独的方法。 (对于我来说,这是一个重要的发现,来自@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被认为是危险的 以及在调试器下发现引用保持活动的问题,这让我早先的测试感到困惑。
我找到 a有用的通用模板,可以帮助实现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 /有用-IDisposable的级-3- autoreleasecomobject /
我不敢相信这个问题困扰了这个世界5年....如果你已经创建了一个应用程序,你需要先关闭它然后再删除链接。
objExcel = new Excel.Application();
objBook = (Excel.Workbook)(objExcel.Workbooks.Add(Type.Missing));
关闭时
objBook.Close(true, Type.Missing, Type.Missing);
objExcel.Application.Quit();
objExcel.Quit();
当您新建一个Excel应用程序时,它会在后台打开一个Excel程序。在释放链接之前,您需要命令excel程序退出,因为该Excel程序不是您的直接控制的一部分。因此,如果链接被释放,它将保持打开状态!
好好编程每个人~~
普通开发人员,您的解决方案都不适用于我, 所以我决定实施一个新的技巧。
首先指定<!> quot;我们的目标是什么?<!> quot; = GT <!>; <!>;我们在任务管理器中的工作后没有看到excel对象<!>
确定。不要挑战并开始摧毁它,但考虑不要破坏并行运行的其他实例os Excel。
因此,获取当前处理器的列表并获取EXCEL进程的PID,然后在完成工作后,我们在进程列表中有一个具有唯一PID的新guest虚拟机,找到并销毁该文件。
LT <!>;请记住,在您的Excel工作期间,任何新的Excel工艺都将被检测为新的并销毁<!> gt; LT <!>;更好的解决方案是捕获新创建的excel对象的PID,然后销毁<!> gt;
Process[] prs = Process.GetProcesses();
List<int> excelPID = new List<int>();
foreach (Process p in prs)
if (p.ProcessName == "EXCEL")
excelPID.Add(p.Id);
.... // your job
prs = Process.GetProcesses();
foreach (Process p in prs)
if (p.ProcessName == "EXCEL" && !excelPID.Contains(p.Id))
p.Kill();
这解决了我的问题,也希望你的问题。
这看起来确实过于复杂了。根据我的经验,只有三个关键的事情可以让Excel正确关闭:
1:确保没有对您创建的Excel应用程序的剩余引用(您应该只有一个;将其设置为null
)
2:致电GC.Collect()
3:必须通过用户手动关闭程序或通过在Excel对象上调用Quit
来关闭Excel。 (请注意,GC.WaitForPendingFinalizers()
将像用户尝试关闭程序一样运行,并且如果有未保存的更改,则会显示确认对话框,即使Excel不可见。用户可以按取消,然后Excel将不会已关闭。)
1需要在2之前发生,但3可以随时发生。
实现此功能的一种方法是使用您自己的类包装互操作Excel对象,在构造函数中创建互操作实例,并使用Dispose实现IDisposable,如
if (!mDisposed) {
mExcel = null;
GC.Collect();
mDisposed = true;
}
这将从你的程序方面清除excel。关闭Excel后(由用户手动或通过调用<=>),该过程将消失。如果该程序已经关闭,则该过程将在<=>调用中消失。
(我不确定它有多重要,但您可能希望在<=>调用之后进行<=>调用,但并不是绝对必须摆脱Excel过程。)
多年来,这对我没有任何问题。请记住,虽然这有效,但实际上你必须优雅地关闭才能工作。如果在清理Excel之前中断程序(通常在调试程序时点击<!>“;停止<!>”),您仍然可以累积excel.exe进程。
要添加Excel不关闭的原因,即使在读取,创建时为每个对象创建直接引用,也是“For”循环。
For Each objWorkBook As WorkBook in objWorkBooks 'local ref, created from ExcelApp.WorkBooks to avoid the double-dot
objWorkBook.Close 'or whatever
FinalReleaseComObject(objWorkBook)
objWorkBook = Nothing
Next
'The above does not work, and this is the workaround:
For intCounter As Integer = 1 To mobjExcel_WorkBooks.Count
Dim objTempWorkBook As Workbook = mobjExcel_WorkBooks.Item(intCounter)
objTempWorkBook.Saved = True
objTempWorkBook.Close(False, Type.Missing, Type.Missing)
FinalReleaseComObject(objTempWorkBook)
objTempWorkBook = Nothing
Next
这里接受的答案是正确的,但也要注意不仅<!>“两个点<!>”;需要避免引用,但也需要避免通过索引检索的对象。您也不需要等到程序结束后才能清理这些对象,最好在可能的情况下创建一个在它们完成后立即清理它们的函数。这是我创建的一个函数,它分配一个名为xlStyleHeader
的样式对象的一些属性:
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]
设置为变量以便清理它(不是因为两个点,它指的是不需要释放的枚举,而是因为我所指的对象to实际上是一个需要释放的Border对象。)
这种事情在标准应用程序中并不是必需的,它们可以很好地自行清理,但在ASP.NET应用程序中,如果你错过了其中一个,无论你多久调用一次垃圾收集器,Excel仍将在您的服务器上运行。
在编写此代码时监视任务管理器时需要注意细节和许多测试执行,但这样做可以省去拼命搜索代码页以找到错过的一个实例的麻烦。这在循环中工作时尤其重要,在循环中,您需要释放对象的EACH INSTANCE,即使它在每次循环时都使用相同的变量名称。
尝试后
- 以相反的顺序释放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();
}
}
我完全遵循了这一点......但我仍然遇到了1000次中的问题。谁知道为什么。是时候拿出锤子......
在实例化Excel Application类之后,我得到了刚刚创建的Excel进程。
excel = new Microsoft.Office.Interop.Excel.Application();
var process = Process.GetProcessesByName("EXCEL").OrderByDescending(p => p.StartTime).First();
然后,一旦我完成了上述所有COM清理工作,我确保该进程没有运行。如果它仍在运行,请将其杀死!
if (!process.HasExited)
process.Kill();
<强>#168 <!>;#176 <!>;#186 <!>;#164 <!>;#248 <!>;#8222 <!>; <!>#184;拍摄Excel程序并咀嚼泡泡糖<!>#184; <!>#8222; <!>#248; <!>#164; <!>#186; <!>#176; <!>#168; 强>
public class MyExcelInteropClass
{
Excel.Application xlApp;
Excel.Workbook xlBook;
public void dothingswithExcel()
{
try { /* Do stuff manipulating cells sheets and workbooks ... */ }
catch {}
finally {KillExcelProcess(xlApp);}
}
static void KillExcelProcess(Excel.Application xlApp)
{
if (xlApp != null)
{
int excelProcessId = 0;
GetWindowThreadProcessId(xlApp.Hwnd, out excelProcessId);
Process p = Process.GetProcessById(excelProcessId);
p.Kill();
xlApp = null;
}
}
[DllImport("user32.dll")]
static extern int GetWindowThreadProcessId(int hWnd, out int lpdwProcessId);
}
您需要注意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;en-us;Q320369
<!>“切勿在COM对象中使用两个点<!>”;避免COM引用泄漏是一个很好的经验法则,但Excel PIA可能会导致泄漏,而不是一见钟情。
其中一种方法是订阅任何Excel对象模型的COM对象所暴露的任何事件。
例如,订阅Application类的WorkbookOpen事件。
关于COM事件的一些理论
COM类通过回调接口公开一组事件。为了订阅事件,客户端代码可以简单地注册实现回调接口的对象,并且COM类将调用其方法以响应特定事件。由于回调接口是COM接口,因此实现对象的任务是减少它为任何事件处理程序接收的任何COM对象的引用计数(作为参数)。
Excel PIA如何公开COM事件
Excel PIA将Excel Application类的COM事件公开为常规.NET事件。每当客户端代码订阅一个.NET事件(强调'a')时,PIA就会创建一个实现回调接口的类的一个实例,并将其注册到Excel
因此,许多回调对象在Excel中注册,以响应来自.NET代码的不同订阅请求。每个事件订阅一个回调对象。
事件处理的回调接口意味着,PIA必须为每个.NET事件订阅请求订阅所有接口事件。它无法挑选。收到事件回调后,回调对象检查关联的.NET事件处理程序是否对当前事件感兴趣,然后调用处理程序或静默忽略回调。
对COM实例引用计数的影响
所有这些回调对象都不会减少它们为任何回调方法接收的任何COM对象(作为参数)的引用计数(即使是对于被忽略的方法)。他们只依靠 CLR 垃圾收集器来释放COM对象。
由于GC运行是不确定的,这可能会导致Excel进程停留的时间超过预期,并产生“内存泄漏”的印象。
解决方案
目前唯一的解决方案是避免使用COM类的PIA <!>#8217; s事件提供程序,并编写自己的事件提供程序,确定性地释放COM对象。
对于Application类,可以通过实现AppEvents接口,然后使用 IConnectionPointContainer界面。 Application类(以及使用回调机制公开事件的所有COM对象)实现IConnectionPointContainer接口。
正如其他人指出的那样,您需要为您使用的每个Excel对象创建一个显式引用,并在该引用上调用Marshal.ReleaseComObject,如这篇知识库文章。您还需要使用try / finally确保始终调用ReleaseComObject,即使抛出异常也是如此。即而不是:
Worksheet sheet = excelApp.Worksheets(1)
... do something with sheet
你需要做类似的事情:
Worksheets sheets = null;
Worksheet sheet = null
try
{
sheets = excelApp.Worksheets;
sheet = sheets(1);
...
}
finally
{
if (sheets != null) Marshal.ReleaseComObject(sheets);
if (sheet != null) Marshal.ReleaseComObject(sheet);
}
如果希望Excel关闭,还需要在释放Application对象之前调用Application.Quit。
正如你所看到的,一旦你尝试做任何中等复杂的事情,这很快变得非常笨拙。我已经成功开发了.NET应用程序,其中包含一个简单的包装类,它包含了Excel对象模型的一些简单操作(打开工作簿,写入范围,保存/关闭工作簿等)。包装器类实现IDisposable,在它使用的每个对象上仔细实现Marshal.ReleaseComObject,并且不会公开地将任何Excel对象公开给应用程序的其余部分。
但是这种方法不能很好地适应更复杂的要求。
这是.NET COM Interop的一大缺陷。对于更复杂的场景,我会认真考虑用VB6或其他非托管语言编写ActiveX DLL,您可以将所有交互委托给Office等外部COM对象。然后,您可以从.NET应用程序中引用此ActiveX DLL,事情将变得更加容易,因为您只需要发布此一个引用。
如果上面的所有内容都不起作用,请尝试让Excel有时间关闭它的表单:
app.workbooks.Close();
Thread.Sleep(500); // adjust, for me it works at around 300+
app.Quit();
...
FinalReleaseComObject(app);
确保释放与Excel相关的所有对象!
我尝试了几种方法花了几个小时。所有这些都是很好的想法,但我终于找到了我的错误:如果你没有发布所有对象,上面没有一种方法可以帮助你就像我的情况一样。确保释放包括范围一在内的所有对象!
Excel.Range rng = (Excel.Range)worksheet.Cells[1, 1];
worksheet.Paste(rng, false);
releaseObject(rng);
选项在一起此处。
两点规则对我不起作用。在我的例子中,我创建了一个方法来清理我的资源,如下所示:
private static void Clean()
{
workBook.Close();
Marshall.ReleaseComObject(workBook);
excel.Quit();
CG.Collect();
CG.WaitForPendingFinalizers();
}
使用Word / Excel互操作应用程序时应该非常小心。在尝试了所有解决方案后,我们仍然有很多<!>“WinWord <!>”;进程在服务器上保持打开状态(超过2000个用户)。
在解决了几个小时的问题之后,我意识到如果我同时在不同的线程上使用Word.ApplicationClass.Document.Open()
打开多个文档,IIS工作进程(w3wp.exe)会崩溃,所有的WinWord进程都会打开!
所以我猜这个问题没有绝对的解决办法,但转而使用其他方法,例如 Office Open XML 开发。
关于发布COM对象的一篇很棒的文章是 2.5释放COM对象 (MSDN)。
我提倡的方法是,如果它们是非局部变量,则将Excel.Interop引用置空,然后再调用GC.Collect()
和GC.WaitForPendingFinalizers()
两次。本地范围的Interop变量将自动处理。
这样就无需为每个 COM对象保留命名参考。
以下是文章中的一个例子:
public class Test {
// These instance variables must be nulled or Excel will not quit
private Excel.Application xl;
private Excel.Workbook book;
public void DoSomething()
{
xl = new Excel.Application();
xl.Visible = true;
book = xl.Workbooks.Add(Type.Missing);
// These variables are locally scoped, so we need not worry about them.
// Notice I don't care about using two dots.
Excel.Range rng = book.Worksheets[1].UsedRange;
}
public void CleanUp()
{
book = null;
xl.Quit();
xl = null;
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();
}
}
这些话直接来自文章:
在几乎所有情况下,清空RCW引用并强制执行垃圾回收都会正确清理。如果你也调用GC.WaitForPendingFinalizers,垃圾收集将尽可能确定。也就是说,您将非常确定该对象何时被清理<!>#8212;从第二次调用WaitForPendingFinalizers返回时。作为替代方案,您可以使用Marshal.ReleaseComObject。但请注意,您不太可能需要使用此方法。
我的解决方案
[DllImport("user32.dll")]
static extern int GetWindowThreadProcessId(int hWnd, out int lpdwProcessId);
private void GenerateExcel()
{
var excel = new Microsoft.Office.Interop.Excel.Application();
int id;
// Find the Excel Process Id (ath the end, you kill him
GetWindowThreadProcessId(excel.Hwnd, out id);
Process excelProcess = Process.GetProcessById(id);
try
{
// Your code
}
finally
{
excel.Quit();
// Kill him !
excelProcess.Kill();
}
接受的答案对我不起作用。析构函数中的以下代码完成了这项工作。
if (xlApp != null)
{
xlApp.Workbooks.Close();
xlApp.Quit();
}
System.Diagnostics.Process[] processArray = System.Diagnostics.Process.GetProcessesByName("EXCEL");
foreach (System.Diagnostics.Process process in processArray)
{
if (process.MainWindowTitle.Length == 0) { process.Kill(); }
}
我目前正致力于Office自动化,并偶然发现了一个适合我的解决方案。它很简单,不涉及杀死任何进程。
似乎只需循环遍历当前活动进程,并以任何方式“访问”一个打开的Excel进程,就会删除任何异常挂起的Excel实例。下面的代码只检查名称为“Excel”的进程,然后将进程的MainWindowTitle属性写入字符串。与进程的这种“交互”似乎使Windows赶上并中止了冻结的Excel实例。
我在加载项之前运行以下方法,我正在开发退出,因为它会触发它卸载事件。它每次都会删除任何挂起的Excel实例。老实说,我并不完全确定为什么会这样,但它适用于我,可以放在任何Excel应用程序的末尾,而不必担心双点,Marshal.ReleaseComObject,也不会杀死进程。我会对任何有效的建议感兴趣。
public static void SweepExcelProcesses()
{
if (Process.GetProcessesByName("EXCEL").Length != 0)
{
Process[] processes = Process.GetProcesses();
foreach (Process process in processes)
{
if (process.ProcessName.ToString() == "excel")
{
string title = process.MainWindowTitle;
}
}
}
}
我认为其中一些只是框架处理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进程,但我可能只是偏执狂。
正如有些人已经写过的那样,你关闭 Excel(对象)的方式并不重要;如何打开以及项目类型也很重要。
在WPF应用程序中,基本相同的代码在没有或几乎没有问题的情况下工作。
我有一个项目,其中为不同的参数值多次处理相同的Excel文件 - 例如基于泛型列表中的值解析它。
我将所有与Excel相关的函数放入基类,并将解析器放入子类(不同的解析器使用常用的Excel函数)。我不希望Excel为通用列表中的每个项目再次打开和关闭,所以我只在基类中打开它一次并在子类中关闭它。将代码移动到桌面应用程序时遇到问题。我尝试了很多上面提到的解决方案。 GC.Collect()
之前已经实施过,建议的两倍。
然后我决定将用于打开Excel的代码移动到子类。现在我不是只打开一次,而是创建一个新对象(基类)并为每个项打开Excel并在最后关闭它。存在一些性能损失,但基于多个测试,Excel进程正在关闭而没有问题(在调试模式下),因此也会删除临时文件。如果我得到一些更新,我会继续测试并写一些。
底线是:您还必须检查初始化代码,特别是如果您有许多类等。