Excel Processus de clôture en VB.net

Manuel de gestion de la mémoire comme cela juste ne fonctionne jamais. C'est un problème qui est connu depuis très longtemps et le coeur, et la raison que les ramasseurs d'ordures ont été inventés. Les programmeurs juste jamais oublier de libérer la mémoire.

Il devient très difficile lorsque vous ne pouvez pas voir la mémoire utilisée. Ce qui est certainement le cas dans votre code, le xlWorkSheet.Cells(i + 1, j + 1) expression utilise pas moins de trois références. L'un pour la gamme de l'objet retourné par la propriété Cellules, une pour un sous-objet de la plage sélectionnée par i+1 et un autre pour le sous-objet de la plage sélectionnée par j+1. Très belle syntaxe de sucre fourni par le VB.NET la langue, l'écriture de code COM sans elle, c'est joli nom de dieu douloureux. Mais pas utile pour vous permettre de voir les références. Non seulement pouvez-vous pas voir dans votre code source, il n'y a absolument rien, le débogueur peut faire pour vous aider à les voir.

C'est bien un problème résolu .NET, il a un garbage collector et il peut voir tout. Le problème principal, c'est que vous ne lui donnez pas une chance de résoudre votre problème. L'erreur que vous faites, c'est que vous arrêté. Probablement en définissant un point d'arrêt sur la dernière déclaration, et puis en regardant dans le Gestionnaire des Tâches et de voir Excel.exe toujours en cours d'exécution. Oui, c'est normal. La collecte des ordures n'est pas instant.

L'appel de GC.Collect() est censé rendre instantané, mais qui ne fonctionne pas dans le cas précis de l'exécution de la version de Débogage de votre projet. La durée de vie des variables locales obtient ensuite étendu à la fin de la méthode, vous aider à les voir dans les Autos/Habitants/Watch fenêtre. En d'autres termes, GC.Collect() ne fait pas de recueillir tout de l'interface de références. Plus sur que le comportement dans ce post.

La solution simple est de pas arrêter. Continuer à faire des choses utiles pour donner le garbage collector une raison de courir. Ou de laisser votre programme de résilier puisqu'il est fait, Excel se termine lorsque le finaliseur thread s'exécute pour la dernière fois. Qui fonctionne parce que les variables locales qui avaient les références ne sont pas dans le champ d'application est plus.

Mais tout le monde veut la correction instantanée de toute façon. Vous l'obtenez par la suppression de tous les releaseObject() appelle. Et de le faire comme ceci à la place:

converToExcel(path, dset)
GC.Collect()
GC.WaitForPendingFinalizers()

Ou en d'autres termes, la force d'une collection après la méthode est de retour. Les variables locales ne sont plus dans le champ d'application de sorte qu'ils ne peuvent pas tenir sur une feuille de référence. Il sera désormais également le travail quand vous le débogage, comme il l'a déjà fait lors de l'exécution de la Libération construire sans un débogueur.

OriginalL'auteur Hans Passant

La GC.Recueillir fait pas beaucoup de sens où vous l'avez placé, si quelque chose vous devriez l'appeler après le retour à la de converToExcel. Aussi, vous pouvez avoir besoin d'attendre pour les finaliseurs à exécuter. Personnellement, je pense que Hans réponse est le chemin à parcourir, mais je sais par expérience personnelle, l'écriture office addins en C# qu'il est parfois nécessaire de le faire en manuel de comptage de référence, en particulier lorsque vous avez besoin pour être compatible avec les anciennes versions d'office. (Il y a beaucoup de problèmes documentés, en particulier lors de la manipulation des événements à partir d'office, qui ne peut être résolu de manière fiable par le manuel de comptage de référence. Aussi certaines bibliothèques COM n'aime pas du tout lorsqu'il est libéré dans le mauvais ordre par GC, mais ce n'est pas le cas avec le bureau.)

Donc le problème dans ton code: il y a trois intermédiaires objets COM pas publié ici:

• xlWorkBook.Sheets retourne une collection de type Excel.Sheets
• xlWorkSheet.Columns retourne un objet COM de type Excel.Range
• xlWorkSheet.Cells renvoie aussi un Excel.Range objet

En outre, si le Maréchal.ReleaseComObject déclenche une exception que vous avez fait quelque chose de mal dans votre manuel de comptage de référence, donc je ne serait pas l'envelopper dans un gestionnaire d'exception. Quand manuel de comptage de référence, vous devez relâcher chaque objet COM une fois pour chaque fois qu'il traverse la COM->NET frontière, ce qui signifie la Excel.Range objets doivent être libérés à chaque itération de la boucle.

Voici le code qui se termine Excel pour moi:

Imports Microsoft.Office.Interop
Imports System.Runtime.InteropServices

Private Sub converToExcel(fileLoc As String, ds As DataSet)
    Dim xlApp As New Excel.Application
    Dim xlWorkBooks As Excel.Workbooks = xlApp.Workbooks
    Dim xlWorkBook As Excel.Workbook = xlWorkBooks.Add(System.Reflection.Missing.Value)
    Dim xlWorkSheets As Excel.Sheets = xlWorkBook.Sheets
    ' accessing the sheet by index because name is localized and your code will fail in non-english office versions
    Dim xlWorkSheet As Excel.Worksheet = xlWorkSheets(1)

    For i = 0 To ds.Tables(0).Rows.Count - 1
        For j = 0 To ds.Tables(0).Columns.Count - 1
            ' couldn't this be moved outside the loop?
            Dim xlColumns As Excel.Range = xlWorkSheet.Columns
            xlColumns.NumberFormat = "@"
            Marshal.ReleaseComObject(xlColumns)

            Dim xlCells As Excel.Range = xlWorkSheet.Cells
            xlCells(i + 1, j + 1) = ds.Tables(0).Rows(i).Item(j).ToString()
            Marshal.ReleaseComObject(xlCells)
        Next
    Next

    xlWorkSheet.SaveAs(fileLoc)
    'xlWorkBook.Close() -- not really necessary
    xlApp.Quit()

    Marshal.ReleaseComObject(xlWorkSheet)
    Marshal.ReleaseComObject(xlWorkSheets)
    Marshal.ReleaseComObject(xlWorkBook)
    Marshal.ReleaseComObject(xlWorkBooks)
    Marshal.ReleaseComObject(xlApp)
End Sub

Si vous voulez être très prudent que vous souhaitez pour gérer les exceptions de l'office de l'API et de l'appel ReleaseComObject à l'intérieur, enfin,-les clauses. Il peut être utile de définir un wrapper générique et écrire à l'aide de clauses relatives au lieu d'essayer, enfin, de faire le wrapper une structure de classe afin de ne pas affecter les wrappers sur le tas).

OriginalL'auteur Zarat

'Get the PID from the wHnd and kill the process.
' open the spreadsheet
ImportFileName = OpenFileDialog1.FileName
excel = New Microsoft.Office.Interop.Excel.ApplicationClass
wBook = excel.Workbooks.Open(ImportFileName)
hWnd = excel.Hwnd
Dim id As Integer = GetWindowThreadProcessId(hWnd, ExcelPID)

Sub CloseExcelFile()
        Try
            ' first try this
            wBook.Saved = True
            wBook.Close()
            excel.Quit()

            ' then this.
            System.Runtime.InteropServices.Marshal.ReleaseComObject(excel)
            excel = Nothing

            ' This appears to be the only way to close excel!
            Dim oProcess As Process
            oProcess = Process.GetProcessById(ExcelPID)
            If oProcess IsNot Nothing Then
                oProcess.Kill()
            End If

        Catch ex As Exception
            excel = Nothing
        Finally
            GC.Collect()
        End Try
    End Sub

OriginalL'auteur Gretchen

Dim xlp() As Process = Process.GetProcessesByName("EXCEL")

 For Each Process As Process In xlp
   Process.Kill()
     If Process.GetProcessesByName("EXCEL").Count = 0 Then
       Exit For
     End If
 Next

OriginalL'auteur Shivachandra