Wie säubere ich Excel-Interop-Objekte ordnungsgemäß?

Excel nicht beenden, da Ihre Anwendung immer noch hält Referenzen auf COM-Objekte.

Ich denke, du bist Berufung mindestens ein Mitglied der COM-Objekt ohne Zuweisung an eine variable.

Für mich war es die excelApp.Arbeitsblätter Objekt, die ich direkt verwendet werden, ohne Zuweisung an eine variable:

Worksheet sheet = excelApp.Worksheets.Open(...);
...
Marshal.ReleaseComObject(sheet);

Wusste ich nicht, dass intern C# erstellt einen wrapper für die Arbeitsblätter COM-Objekt, das nicht veröffentlicht wird durch meinen code (weil ich war nicht bewusst) und war die Ursache, warum Excel nicht entladen.

Fand ich die Lösung zu meinem problem auf auf dieser Seitedie hat auch eine nette Regel für die Verwendung von COM-Objekten in C#:

Verwenden Sie niemals zwei Punkte mit COM-Objekten.

Also mit diesem wissen auf die richtige Weise zu tun, die oben genannten ist:

Worksheets sheets = excelApp.Worksheets; //<-- The important part
Worksheet sheet = sheets.Open(...);
...
Marshal.ReleaseComObject(sheets);
Marshal.ReleaseComObject(sheet);

InformationsquelleAutor der Antwort VVS

Vorwort: meine Antwort enthält zwei Lösungen, also seien Sie vorsichtig beim Lesen und nichts verpassen.

Gibt es verschiedene Möglichkeiten und Tipps, wie man Excel-Instanz entladen, wie:

• Freigabe JEDES com-Objekt explizit
  mit dem Marschall.FinalReleaseComObject()
  (nicht zu vergessen, über implizit
  erstellt von com-Objekten). Zu release
  jeder erstellte com-Objekt, die Sie verwenden können
  die Regel von 2 Punkten die hier erwähnt werden:
  
  Wie kann ich richtig aufzuräumen Excel-interop-Objekte?

• Aufruf von GC.Collect() und
  GC.Waitforpendingfinalizers Tauchen() zu machen
  CLR-Version nicht verwendete com-Objekte * (Tatsächlich, es funktioniert, siehe meine zweite Lösung für die details)

• Überprüfen, ob die com-server-Anwendung
  vielleicht zeigt eine message-box warten
  der user zu beantworten (obwohl ich nicht bin
  sicher, es kann verhindern, dass Excel aus
  schließen, aber ich hörte es ein paar
  mal)

• Senden von WM_CLOSE-Meldung auf der main
  Excel-Fenster

• Ausführen der Funktion, die funktioniert
  mit Excel in einer separaten Anwendungsdomäne.
  Einige Leute glauben Excel-Instanz
  wird geschlossen, wenn AppDomain ist
  entladen.

• Tötung aller excel-Instanzen, die instanziiert wurden nach unserer excel-interoping-code begann.

ABER! Manchmal alle diese Optionen einfach nicht helfen, oder kann nicht angemessen sein!

Zum Beispiel, gestern fand ich heraus, dass in einer meiner Funktionen (mit excel) Excel behält ausgeführt wird, nachdem die Funktion beendet. Ich habe alles versucht! Ich sorgfältig geprüft, die ganze Funktion 10 mal und fügte Marschall.FinalReleaseComObject() für alles! Ich hatte auch GC.Collect() und GC.Waitforpendingfinalizers Tauchen(). Ich überprüfte für die versteckte message-Boxen. Ich versuchte, senden von WM_CLOSE-Nachricht zu der Haupt-Excel-Fenster. Ich ausgeführt meine Funktion in eine separate AppDomain-und entladen, die domain. Nichts hat geholfen! Die option mit dem schließen aller excel-Instanzen ist unpassend, weil, wenn der Benutzer beginnt eine weitere Excel-Instanz manuell, während der Ausführung der Funktion, die funktioniert auch mit Excel, dann diese Instanz auch geschlossen werden von meiner Funktion. Ich Wette, der Benutzer wird nicht glücklich sein! Also, ehrlich gesagt, das ist ein lame-option (nichts für ungut Jungs). So verbrachte ich ein paar Stunden, bevor ich einziehen (meiner bescheidenen Meinung nach) Lösung: Töten excel-Prozess durch die hWnd-Eigenschaft des das Hauptfenster (es ist eine erste Lösung).

Ist hier der einfache code:

[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();
}

Wie Sie sehen können habe ich zwei Methoden, nach Try-Parse-Muster (ich denke es ist hier angebracht): eine Methode keine Ausnahme auslösen, wenn der Prozess konnte nicht getötet werden (zum Beispiel der Prozess existiert nicht mehr), und eine andere Methode wirft Ausnahme, falls der Prozess wurde nicht getötet. Die einzige schwache Stelle in diesem code wird die Sicherheit Berechtigungen. Theoretisch, kann der Benutzer nicht die Berechtigung hat, den Prozess zu beenden, aber in 99.99% aller Fälle wird der Benutzer die entsprechenden Berechtigungen besitzt. Ich habe auch getestet mit einem Gast-Konto - es funktioniert perfekt.

So, Ihr code, arbeiten mit Excel, kann wie folgt Aussehen:

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

Voila! Excel ist beendet! 🙂

Ok, gehen wir zurück zu der zweiten Lösung, wie ich versprach, in der Anfang der post.
Die zweite Lösung ist der Aufruf von GC.Collect() und GC.Waitforpendingfinalizers Tauchen(). Ja, Sie tatsächlich arbeiten, aber Sie müssen hier vorsichtig sein!

Viele Menschen sagen (und ich sagte), dass der Aufruf von GC.Collect() nicht helfen. Aber der Grund, warum es nicht hilft, ist, wenn es noch Referenzen auf COM-Objekte! Einer der beliebtesten Gründe für die GC.Collect() nicht hilfreich ist, läuft das Projekt im Debug-Modus. Im debug-Modus-Objekte, sind wirklich nicht mehr referenziert werden, werden nicht von der garbage Collection eingesammelt, bis das Ende der Methode.

Also, wenn Sie versucht, die GC.Collect() und GC.Waitforpendingfinalizers Tauchen() und es hat nicht helfen, versuchen Sie Folgendes:

1) Versuchen Sie, führen Sie Ihr Projekt im Release-Modus und überprüfen Sie, ob Excel richtig geschlossen

2) Wickeln Sie die Methode, die das arbeiten mit Excel in eine separate Methode.
Also, statt so etwas wie dieses:

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

schreiben Sie:

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)
    ...
  }
}

Nun in Excel in der Nähe =)

InformationsquelleAutor der Antwort nightcoder

Dieser arbeitete für ein Projekt, das ich arbeiten war:

excelApp.Quit();
Marshal.ReleaseComObject (excelWB);
Marshal.ReleaseComObject (excelApp);
excelApp = null;

Haben wir gelernt, dass es wichtig war, zu setzen jeder Verweis auf eine Excel-COM-Objekt auf null, wenn Sie fertig waren. Diese enthalten Zellen, Blätter und alles.

InformationsquelleAutor der Antwort Philip Fourie

Ich gefunden eine nützliche generische Vorlage, die helfen kann, implementieren Sie die korrekte Entsorgung ein Muster für COM-Objekte, die Marschall.ReleaseComObject aufgerufen wird, wenn Sie gehen out of scope:

Verwendung:

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();
    } 
}

Vorlage:

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;
        }
    }
}

Referenz:

http://www.deez.info/sengelha/2005/02/11/useful-idisposable-class-3-autoreleasecomobject/

InformationsquelleAutor der Antwort Edward Wilde

Erste - Sie nie zu nennen Marshal.ReleaseComObject(...) oder Marshal.FinalReleaseComObject(...) tun, wenn Excel-interop. Es ist eine verwirrende anti-pattern, aber keine Informationen über dieses, auch von Microsoft, die anzeigt, müssen Sie manuell freigeben COM-Verweise aus .NET falsch. Die Tatsache ist, dass die .NET-runtime und garbage collector korrekt nachverfolgen und bereinigen die COM-Verweise. Für deinen code, das heißt, Sie können entfernen Sie das gesamte " while (...) Schleife an der Spitze.

Sekunde, wenn Sie wollen, um sicherzustellen, dass die COM-Verweise, um eine out-of-process-COM-Objekt bereinigt werden, wenn ein Prozess beendet wird (so dass der Excel-Prozess wird in der Nähe), die Sie benötigen, um sicherzustellen, dass der garbage collector ausgeführt wird. Sie machen das richtig mit anrufen zu GC.Collect() und GC.WaitForPendingFinalizers(). Der Aufruf dieser zweimal ist sicher und gewährleistet, dass die Zyklen sind definitiv bereinigt zu (obwohl ich nicht sicher bin ob es benötigt wird, und würde schätzen, ein Beispiel, das zeigt dieser).

Dritten bei der Ausführung im debugger lokale Referenzen werden künstlich am Leben gehalten, bis das Ende der Methode (so dass die lokalen Variablen arbeiten). So GC.Collect() Anrufe sind nicht wirksam für die Reinigung Objekt wie rng.Cells von der gleichen Methode. Sie aufteilen soll der code tun, die COM-interop von der GC Aufräumen in separate Methoden. (Dies war eine wichtige Entdeckung für mich, von einem Teil der Antwort hier gepostet von @nightcoder.)

Das Allgemeine Muster wäre also:

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

Es gibt eine Menge falscher Informationen und die Verwirrung über dieses Thema, darunter auch viele Beiträge auf der MSDN-Website und auf Stack Overflow (und vor allem dieser Frage!).

Was hat mich schließlich überzeugt zu haben, genauer hinzuschauen und herauszufinden, die richtige Beratung war blog-post Marschall.ReleaseComObject Als Gefährlich Eingestuft zusammen mit der Suche nach dem Problem mit Referenzen am Leben gehalten, unter dem debugger, das war verwirrend meiner früheren Tests.

InformationsquelleAutor der Antwort Govert

Akzeptierte Antwort hier richtig ist, aber beachten Sie auch, dass nicht nur "zwei Punkt" Referenzen müssen vermieden werden, aber auch Objekte, die abgerufen werden über den index. Sie brauchen auch nicht zu warten, bis Sie fertig sind mit dem Programm zu bereinigen, diese Objekte, es ist am besten zum erstellen von Funktionen, reinigen Sie Sie, sobald Sie fertig sind mit Ihnen, wenn möglich. Hier ist eine Funktion, die ich erstellt, weist einige Eigenschaften eines Style-Objekt aufgerufen 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 { } 
}

Beachten Sie, dass ich musste xlBorders[Excel.XlBordersIndex.xlEdgeBottom] auf eine variable, um Sie zu reinigen, (Nicht wegen der zwei Punkte, die sich auf eine Aufzählung, die nicht freigegeben werden müssen, sondern weil das Objekt das ich mich beziehe, ist tatsächlich ein Border-Objekt, die freigegeben werden müssen).

Diese Art der Sache ist nicht wirklich notwendig in standard-Anwendungen, die machen einen tollen job, Aufräumarbeiten nach sich selbst, sondern in ASP.NET Anwendungen, wenn Sie verpassen auch nur eine von diesen, egal wie oft Sie den Aufruf der garbage collector, Excel wird immer noch ausgeführt werden, auf Ihren server.

Es erfordert eine Menge Aufmerksamkeit zum detail und viele test-Ausführungen, während die überwachung der Task-Manager, wenn Sie schreiben den code, aber damit spart man sich die mühevolle verzweifelt auf der Suche durch die Seiten code zu finden, der einen Instanz, die Sie verpasst. Dies ist besonders wichtig bei arbeiten in Schleifen, wo Sie brauchen, um release JEDE INSTANZ ein Objekt ist, obwohl es verwendet die gleichen Variablen-Namen jedes mal, wenn Sie es Schleifen.

InformationsquelleAutor der Antwort Chris McGrath

Diese scheint sicher, dass es über-kompliziert. Aus meiner Erfahrung gibt es nur drei wichtige Dinge, um Excel richtig zu schließen:

1: stellen Sie sicher, es gibt keine verbleibenden Verweise auf die excel-Anwendung, die Sie erstellt haben (Sie sollten nur ein wie auch immer; setzen Sie es auf null)

2: rufen Sie GC.Collect()

3: Excel geschlossen werden, entweder durch den Benutzer manuell schließen Sie das Programm, oder rufen Sie Quit auf die Excel-Objekt. (Beachten Sie, dass Quit wird funktionieren, wie wenn der Benutzer versucht, das Programm zu schließen, und wird ein Bestätigungs-Dialogfeld, wenn ungespeicherte änderungen vorhanden sind, auch wenn Excel nicht sichtbar ist. Der Benutzer kann auf Abbrechen drücken, und dann wird Excel nicht geschlossen worden.)

1 geschehen muss, bevor 2, aber 3 kann jederzeit passieren.

Eine Möglichkeit dies umzusetzen ist, wickeln Sie die interop-Excel-Objekt mit Ihrer eigenen Klasse, erstellen Sie die interop-Instanz im Konstruktor und implementieren Sie IDisposable mit Dispose Suche so etwas wie

if (!mDisposed) {
   mExcel = null;
   GC.Collect();
   mDisposed = true;
}

Bereinigt excel aus Ihrem Programm-Seite der Dinge. Sobald Excel geschlossen wird (manuell durch den Benutzer oder rufen Sie Quit) der Prozess, der Weg gehen wird. Wenn das Programm schon geschlossen ist, dann wird der Prozess verschwindet auf der GC.Collect() nennen.

(Ich bin mir nicht sicher, wie wichtig es ist, aber möchten Sie vielleicht einen GC.WaitForPendingFinalizers() Anruf nach der GC.Collect() nennen, aber es ist nicht unbedingt notwendig, um loszuwerden, der Excel-Prozess.)

Dies funktionierte bei mir ohne Problem für Jahre. Halten Sie im Verstand, obwohl, dass, während dies funktioniert, müssen Sie in der Nähe anmutig für ihn zu arbeiten. Sie erhalten weiterhin akkumulieren excel.exe Prozesse, wenn Sie unterbrechen Ihr Programm, bevor Excel bereinigt (in der Regel durch drücken der "Stopp", während das Programm gedebuggt wird).

InformationsquelleAutor der Antwort Dave Cousineau

Habe ich traditionell folgte die Beratung in VVS Antwort. Jedoch, in einer Anstrengung, um diese Antwort up-to-date mit den neuesten Möglichkeiten, ich denke, dass alle meine zukünftigen Projekte verwenden Sie die "NetOffice" Bibliothek.

NetOffice ist ein vollständiger Ersatz für die Office-PIAs und ist komplett version-Agnostiker. Es ist eine Sammlung von Verwalteten COM-Wrapper, kann mit den Aufräumarbeiten, verursacht oft Kopfschmerzen bei der Arbeit mit Microsoft Office .NET.

Einige der wichtigsten features sind:

• Meist version-unabhängig ist (und version-abhängigen Funktionen dokumentiert sind)
• Keine Abhängigkeiten
• Keine PIA
• Keine Anmeldung
• Keine VSTO

Ich bin in keiner Weise verbunden mit dem Projekt, ich habe Sie nur wirklich schätzen die krasse Reduktion von Kopfschmerzen.

InformationsquelleAutor der Antwort BTownTKD

Müssen Sie sich bewusst sein, dass Excel sehr empfindlich auf die Kultur, die Sie unter sowie.

Können Sie feststellen, dass Sie brauchen, um die Kultur EN-US vor dem Aufruf von Excel-Funktionen.
Dies gilt nicht für alle Funktionen - aber einige von Ihnen.

    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;

Dies gilt auch dann, wenn Sie mit VSTO.

Details: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q320369

InformationsquelleAutor der Antwort

"Verwenden Sie niemals zwei Punkte mit COM-Objekten" ist eine gute Faustregel, um zu vermeiden Leckage von COM-Verweise, aber Excel PIA kann führen zu Leckagen in mehr als offensichtlich auf den ersten Blick.

Einer dieser Wege ist die Anmeldung zu jeder Veranstaltung ausgesetzt, die durch die Excel-Objekt-Modell der COM-Objekte.

Zum Beispiel, Abonnement, um die Application-Klasse ist WorkbookOpen-Ereignis.

Einige Theorie auf COM-Ereignisse

COM-Klassen setzen eine Gruppe von Ereignissen durch call-back-Schnittstellen. Um Ereignisse zu abonnieren, die mit dem client-code registrieren Sie sich einfach ein Objekt der Implementierung der call-back-Schnittstelle und der COM-Klasse werden die Methoden aufrufen, die in Reaktion auf bestimmte Ereignisse. Da die call-back-Schnittstelle eine COM-Schnittstelle, ist es die Pflicht der Umsetzung-Objekt dekrementiert den Verweiszähler von jedem COM-Objekt erhält (als parameter) für den Ereignis-Handler.

Wie Excel PIA aussetzen COM-Ereignisse

Excel-PIA stellt COM-Ereignisse von Excel-Application-Klasse als konventionelle .NET-events. Wenn der client-code abonniert ein .NET event (Betonung auf 'a'), PIA schafft eine Instanz einer Klasse die Implementierung der call-back-Schnittstelle und registriert Sie mit Excel.

Daher, eine Nummer des call-back-Objekte registriert mit Excel in der Reaktion auf die verschiedenen Abonnement-Anfragen aus .NET-code. Ein call-back-Objekt pro Ereignis-Abonnement.

Einen call-back-Schnittstelle für event-handling bedeutet, dass, PIA hat zu abonnieren, um alle Schnittstellen-Ereignisse für jeden .NETZ-Ereignis-Abonnement-Anfrage. Es kann nicht wählen, und wählen. Auf ein Ereignis empfangen call-back, call-back-Objekt prüft, ob der Zusammenhang .NET event handler ist daran interessiert, das current-Ereignis ist oder nicht und dann entweder ruft der hf oder ignoriert die call-back.

Wirkung auf die COM Instanz Referenzzähler

All diese call-back Objekte nicht dekrementiert den Verweiszähler jede von der COM-Objekte, die Sie erhalten (als Parameter) für alle von der call-back-Methoden (auch für diejenigen, die werden stillschweigend ignoriert). Sie verlassen sich ausschließlich auf die CLR garbage collector freizugeben, die COM-Objekte.

Da GC-Ausführung ist nicht-deterministisch, das kann dazu führen das der Betrieb aus der Excel-Prozess für eine längere Dauer als gewünscht, und erstellen Sie einen Eindruck von einem 'memory leak'.

Lösung

Die einzige Lösung besteht derzeit darin, zu vermeiden, die PIA ist event-provider für die COM-Klasse und schreiben Sie Ihre eigene event-Anbieter, die deterministisch Versionen von COM-Objekten.

Für die Anwendung Klasse, diese kann getan werden, durch die Umsetzung der AppEvents-Schnittstelle und registrieren die Umsetzung mit Excel, mit IConnectionPointContainer-Schnittstelle. Die Anwendung der Klasse (und für diese Angelegenheit alle COM-Objekte freilegen-events mit callback-Mechanismus) die IConnectionPointContainer-Schnittstelle implementiert.

InformationsquelleAutor der Antwort Amit Mittal

Wenn alle die Sachen, die oben nicht funktioniert, versuchen Sie geben Sie Excel einige Zeit, um in der Nähe seiner Blätter:

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

...
FinalReleaseComObject(app);

InformationsquelleAutor der Antwort spiderman

Den zwei-Punkte-Regel hat nicht funktioniert für mich. In meinem Fall erstellte ich eine Methode, um zu reinigen meine Ressourcen wie folgt:

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

InformationsquelleAutor der Antwort Hahnemann

Einen großen Artikel über die Freigabe von COM-Objekten ist 2.5 Freigabe von COM-Objekten (MSDN).

Die Methode, die ich befürworten würde, ist null Ihr Excel.Interop-Referenzen, wenn Sie sind nicht-lokale Variablen und rufen dann GC.Collect() und GC.WaitForPendingFinalizers() zweimal. Lokal gültigen Interop-Variablen werden automatisch erledigt.

Damit entfällt die Notwendigkeit, halten Sie eine benannte Referenz für jeder COM-Objekt.

Hier ist ein Beispiel aus dem Artikel:

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();
    }
}

Diese Worte sind direkt aus dem Artikel:

In fast allen Situationen, Abgleich der RCW Referenz und zwingt eine garbage collection wird richtig Aufräumen. Wenn Sie auch den Aufruf von GC.Waitforpendingfinalizers Tauchen, garbage collection wird als deterministisch wie du es machen kannst. Das heißt, Sie werden ziemlich sicher genau, wenn das Objekt aufgeräumt wurde—auf dem Rückweg vom zweiten Aufruf waitforpendingfinalizers Tauchen. Als alternative können Sie verwenden, Marschall.ReleaseComObject. Beachten Sie jedoch, dass Sie sehr unwahrscheinlich, dass jemals brauchen werden, um diese Methode zu verwenden.

InformationsquelleAutor der Antwort

Akzeptiert die Antwort nicht für mich arbeiten. Der folgende code im Destruktor hat den job.

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(); }
}

InformationsquelleAutor der Antwort Martin

Ich denke, dass einige, die genau so ist, dass das framework übernimmt Office-Anwendungen, aber ich könnte falsch sein. An manchen Tagen, einige Anwendungen bereinigen, die Prozesse sofort, und an anderen Tagen scheint es, zu warten, bis die Anwendung geschlossen wird. In allgemein, beende ich die Aufmerksamkeit auf die details und stellen Sie sicher, dass es keine zusätzlichen Prozesse im Umlauf am Ende des Tages.

Auch, und vielleicht bin ich über die Vereinfachung Dinge, aber ich denke, man kann nur...

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();

Wie gesagt, ich glaube nicht, neigen dazu, die Aufmerksamkeit auf die details, wenn Sie die Excel-Prozess angezeigt wird oder verschwindet, aber das funktioniert in der Regel für mich. Ich weiß auch nicht wie zu halten, Excel-Prozesse, um für etwas anderes als die minimale Menge an Zeit, aber ich bin wahrscheinlich einfach nur paranoid.

InformationsquelleAutor der Antwort bill_the_loser