Widziałem wiele artykułów i pytań dotyczących tego, jak upewnić się, że program Excel faktycznie kończy pracę, gdy tego chcesz, a proces nie trwa.Oto artykuł z bazy wiedzy opis problemu i zalecane przez Microsoft rozwiązanie. Głównie:

'close files

'Quit Excel
xlApp.quit()

'Release and collect garbage
System.Runtime.InteropServices.Marshal.FinalReleaseComObject(xlApp)
GC.Collect()
GC.WaitForPendingFinalizers()

Wiele osób nie zaleca zabijania procesu; WidziećJak prawidłowo oczyścić obiekty interopowe programu Excel iZrozumienie zbierania śmieci w .net

Z drugiej strony wiele osób nie zaleca używania GC.Collect. WidziećCo jest nie tak w korzystaniu z GC.Collect ()?

Z mojego doświadczenia wynika, że ​​zabicie tego procesu jest najszybszym i najłatwiejszym sposobem na upewnienie się, że program Excel zniknął. Mój kod zabija tylko dokładny proces, który rozpoczyna, nie ma innego. Upewnij się, że zamknięto wszystkie otwarte skoroszyty, Zamknij aplikację i zwolnij obiekt xlApp. W końcu sprawdzam, czy proces jest wciąż żywy, a jeśli tak, zabij go.

<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

Widziałem wielu ludzi, którzy twierdzą, że zabijanie procesu jest złe, ale nie widziałem żadnych jakościowych odpowiedzi na pytanie, dlaczego. Zwłaszcza po upewnieniu się, że pliki są zamknięte, program Excel zakończył pracę i zabijemy tylko dokładny proces, który rozpoczęliśmy. Moje pytanie brzmi, jakie są potencjalne problemy z zabiciem procesu Excel. Czy to boli występ? Czy zaszkodzi to Excelowi?

Wielu powie również, że przy dobrym kodowaniu nie muszę zabijać procesu. Może, ale to nie odpowiada na pytanie „Dlaczego zabicie procesu jest złe?” Po zamknięciu plików, zamknięciu programu Excel i zwolnieniu obiektów; dlaczego miałoby być złe, aby upewnić się, że proces się skończył?

Edycja: również to, co zostało właściwie po zamknięciu programu Excel? Jeśli program Excel był widoczny, wydaje się, że kończy się normalnie, znika z widoku iz paska zadań. Czy Excel rzeczywiście zrezygnował lub nie. Wydaje mi się, że Excel rzeczywiście zakończył pracę i że działa tylko pusta powłoka procesowa. Czy ktoś może to skomentować?

Edycja: Interesujące jest dla mnie zauważenie, że GC (aka Garbage Collection) za pośrednictwem GC.Collect () GC.WaitForPendingFinalizers () faktycznie zwolni powłokę procesową, która pozostała po zamknięciu programu Excel. Czy to wspiera moje przypuszczenie, że pusta powłoka procesowa jest w rzeczywistości śmieciami?

Edytuj: właśnie znalazłem doskonałą stronę internetową dotyczącą problemu:50 sposobów na zabicie Excela