D_B*_*ter 4 .net c# vb.net excel excel-interop
我已经看过很多文章和问题,关于如何确保Excel实际上在你想要的时候退出并且这个过程不能保持活力.这是一篇描述该问题的知识库文章和Microsoft推荐的解决方案.实质上:
'close files
'Quit Excel
xlApp.quit()
'Release and collect garbage
System.Runtime.InteropServices.Marshal.FinalReleaseComObject(xlApp)
GC.Collect()
GC.WaitForPendingFinalizers()
Run Code Online (Sandbox Code Playgroud)
很多人不建议杀死这个过程; 请参见 如何正确清理Excel互操作对象 和了解.net中的垃圾收集
另一方面,许多人不建议使用GC.Collect.请参阅使用GC.Collect()有什么错误?
根据我的经验,杀死该过程是确保Excel消失的最快速,最简单的方法.我的代码只会杀死它启动的确切进程,而不会杀死其他进程.我确保关闭所有打开的工作簿,退出应用程序并释放xlApp对象.最后,我检查过程是否仍然存在,如果是,那么杀死它.
<System.Runtime.InteropServices.DllImport("user32.dll", SetLastError:=True)> _
Private Shared Function GetWindowThreadProcessId(ByVal hWnd As IntPtr, _
ByRef lpdwProcessId As Integer) As Integer
End Function
Sub testKill()
'start the application
Dim xlApp As Object = CreateObject("Excel.Application")
'do some work with Excel
'close any open files
'get the window handle
Dim xlHWND As Integer = xlApp.hwnd
'this will have the process ID after call to GetWindowThreadProcessId
Dim ProcIdXL As Integer = 0
'get the process ID
GetWindowThreadProcessId(xlHWND, ProcIdXL)
'get the process
Dim xproc As Process = Process.GetProcessById(ProcIdXL)
'Quit Excel
xlApp.quit()
'Release
System.Runtime.InteropServices.Marshal.FinalReleaseComObject(xlApp)
'set to nothing
xlApp = Nothing
'kill the process if still running
If Not xproc.HasExited Then
xproc.Kill()
End If
End Sub
Run Code Online (Sandbox Code Playgroud)
我见过很多人说杀死这个过程很糟糕,但我没有看到任何定性答案.特别是在确保文件关闭后,Excel已经退出,我们只会杀死我们开始的确切进程.我的问题是杀死Excel进程的潜在问题是什么.这会伤害性能吗?它会损害Excel吗?
许多人还会说,通过良好的编码,我不必杀死这个过程.也许吧,但这并没有回答"杀死这个过程为什么不好?"的问题.关闭文件后,退出Excel并释放对象; 为什么要确保过程消失是不是一件坏事?
编辑:Excel退出后实际上还剩下什么?如果Excel可见,它似乎正常退出,从视图和任务栏中消失.那么Excel实际上是退出还是没有.在我看来,Excel实际上已经退出,我们只有一个空的进程shell运行.谁能对此发表评论?
编辑:有趣的是我注意到GC(也就是垃圾收集)通过GC.Collect()GC.WaitForPendingFinalizers()实际上会释放Excel退出后留下的进程shell.这是否支持我的假设,即空进程shell毕竟是垃圾?
编辑:刚刚找到一个关于问题的优秀网站:50种杀死Excel的方法
看,事实是,如果可能的话,你应该总是让应用程序正常退出.杀死应用程序是最后的选择.我知道你确信你在这种情况下没有看到任何错误,也许你是对的.即使你的系统绝对没有任何负面影响杀死它,这并不会改变这样做的事实.这就像违法一样,因为你知道你不会被抓住,而且无论如何这都是无受害者的犯罪.
但是,您可能没有意识到潜在的副作用.例如,当您强制终止应用程序时,操作系统可能会为其保留崩溃数据.或者它可能会向Microsoft发送崩溃遥测.你实际上是在告诉微软应用程序实际崩溃的频率更高,导致他们的崩溃统计数据略有偏差.
另一个可能的副作用是注册表配置单元可能无法正确卸载.您可能不时在事件日志中看到此错误.它通常发生在强制关闭应用程序并且没有正确关闭注册表的句柄时.
即使这些事情都不会发生,您也无法知道操作系统的未来版本可能会做什么.什么在今天有效,明天可能无效.这就是为什么你应该总是遵循所记录的API和指南,因为它们通常会非常努力地支持他们发布的内容,但通常不会很难支持他们明确告诉你不要做的事情.
| 归档时间: |
|
| 查看次数: |
2017 次 |
| 最近记录: |