Libération garantie des objets COM ?

Question

J'ai écrit le code suivant en partant du principe qu'Excel mourra avec Monkey :

class ExcelMonkey
{
    private static Excel.Application xl = new Excel.Application();

    public static bool parse(string filename)
    {

        if (filename.Contains("foo"))
        { 
            var workbook = xl.Workbooks.Open(filename);
            var sheet = workbook.Worksheets.get_Item(1);

            // do stuff

            return true;

        }

        return false;
    }
}

Comment puis-je m'assurer que c'est le cas ? Dois-je libérer workbook y sheet séparément ?

Je veux avoir Excel pendant toute la durée de vie du programme, c'est une énorme amélioration des performances.

Answer 1

Dois-je publier le classeur et la feuille séparément ?

Oui, l'un ou l'autre maintiendra en vie l'objet Application Excel sous-jacent.

Comment puis-je m'assurer que c'est le cas ?

Marshal.ReleaseComObject le fera, mais assurez-vous de ne pas utiliser de références à l'objet après cela.

Answer 2

Voici la solution qui fonctionne, au cas où cela intéresserait quelqu'un :

class ExcelMonkey
{
    private Excel.Application xl = new Excel.Application();

    ~ExcelMonkey()
    {
        xl.Quit();
        Dispose(false);
    }

    private bool isDisposed = false;

    protected void Dispose(bool disposing)
    {
        Marshal.ReleaseComObject(xl);
        isDisposed = true;
    }

    public bool parse(string filename)
    {
        if (filename.Contains("foo"))                  
        {
            var workbook = xl.Workbooks.Open(filename);
            var sheet = workbook.Worksheets.get_Item(1);

            try
            {
                // do stuff
            }
            finally
            {
                Marshal.ReleaseComObject(sheet);
                Marshal.ReleaseComObject(workbook);
            }
            return true;
        }
        return false;
    }
}

Answer 3

À titre d'information, Excel a tendance à générer des références cachées dans les coulisses en fonction des mécanismes COM par défaut utilisés pour prendre en charge VBA. Par exemple, si vous vous adressez à "Application", celle-ci créera tranquillement une référence COM dont vous ne pourrez pas vous détacher.

Vous devez toujours être assez méticuleux avec les références COM lorsque vous programmez Excel.

Ce problème est aggravé par le fait que les PIA aiment aussi générer des références en arrière-plan et qu'ils ne nettoient pas correctement ces références lors de la collecte des déchets. Vous devez fermer explicitement toute référence COM.

Answer 4

Si vous voulez travailler avec des fichiers de bureau, je vous recommande de jeter un coup d'oeil à NPOI lib . Il s'agit d'un portage en dot net de la librairie POI pour java ; elle fonctionne sans problème lorsqu'on travaille avec des fichiers Office. Pas besoin de COM, tout est fait en code CLR, tout fonctionne comme prévu.

Je l'ai utilisé pour générer des rapports Excel sans aucun problème. Essayez-le, je suis sûr que vous ne le regretterez pas. Bien mieux que d'utiliser COM

Answer 5

Dans l'appel au destructeur

xl.Quit() ;