Lors d’un précédent ticket, j’ai brièvement décrit comment invoquer un objet .NET à partir d’un client COM écrit en VB (non managé).

Pour rappel cela se fait par l’intermédiaire d’un wrapper CCW (COM Callable Wrapper). Le CCW est un objet COM non managé qui est créé par le CLR au même titre que l’objet .NET qu’il encapsule. Toutefois, contrairement au client .NET qu'il enveloppe, le wrapper CCW fait l'objet d'un décompte de références selon le mode COM standard. Quand le décompte de références du wrapper CCW atteint zéro, le wrapper libère sa référence à l'objet managé. Un objet managé sans aucune référence restante est collecté lors du cycle garbage collection suivant. (cf. lien msdn suivant : http://msdn.microsoft.com/en-us/library/f07c8z1c.aspx)

Aussi, il est nécessaire que le CCW soit « déréférencé » par le client COM VB pour que les objets managés .NET qu’il référence soient également détruits par le garbage collector. Etant de nature plutôt méfiante lorsqu’il s’agit d’interopérabilité COM / .NET et n’étant un as du VB ;-), il me paraissait utile de vérifier cela via un profiler de mémoire. J’avais utilisé il y a quelques années de cela chez un ce mes clients préférés l’utilitaire Optimize-it de Borland. Mais celui-ci n’a semble t’il plus évolué depuis le Framework 1.1. Il en existe beaucoup en .NET mais assez peu sont capables de remonter les objets managés et les objets non managés.   J’en ai trouvé un plutôt sympa qui m’a apporté le service que j’attendais. Il s’agit de « .NET Memory Profiler 3.1 » de la société SciTeck Software (http://memprofiler.com). Le soft m’a permis de m’attacher au processus client, de prendre des photos (snapshot) à différents intervalles et après plusieurs sollicitations je me suis aperçu que les objets .NET étaient bien libérés par le garbage collector. La preuve en 2 images… ;-)  

Snapshot 1 :

Conclusion : l’interopérabilité COM / .NET, « ça marche pas pas si mal que cela » !

Laurent Nyffels