Réponses:
Plus particulièrement, libérez toujours explicitement les curseurs lorsque vous en avez fini avec eux. Je publie également certains objets d'énumération qui impliquent un accès à la base de données, par exemple IEnumRelationship que vous obtenez de IRelationshipClass.GetRelationshipsForObject .
En outre, lorsque vous créez un grand nombre d'instances COM de courte durée (en particulier dans les boucles étroites), il est également judicieux de les publier explicitement.
Il existe également des scénarios où il est conseillé de publier des références de fonction (ligne) individuelles. Par exemple, si vous créez une nouvelle version de géodatabase, modifiez des données, rapprochez et publiez, les tentatives de suppression de la version par la suite peuvent échouer car il peut y avoir des lignes non publiées, qui à leur tour gardent la référence à la version (espace de travail) que vous essayez de supprimer. Cependant, la plupart du temps, de tels scénarios sont rares et vous n'avez pas besoin d'en tenir compte dans votre développement ArcObjects au quotidien. Cela ne ferait qu'encombrer le code avec un nettoyage étranger, le rendant moins maintenable.
Il est également important de dire quand ne pas publier les wrappers .NET - ne libérez jamais explicitement RCW d'ArcObjects qui pourraient être utilisés par tout autre code managé. Un exemple de cela - ne libérez pas IMap dans ArcMap. En général, n'essayez pas de libérer ArcObjects que vous n'avez pas créé.
Pour la plupart, la récupération de place .NET fonctionne bien. Il existe certains cas dans ArcObjects qui effectuent un travail important sur les destructeurs et la nature non déterministe des wrappers .NET peut provoquer des problèmes. Cette rubrique d'aide couvre les principaux cas de préoccupation et comment gérer les versions.
Détruisez toujours:
Faites attention de ne pas détruire quelque chose qui est utilisé ailleurs.
Aujourd'hui, j'ai lu une discussion intéressante sur le site Web des ESRI à laquelle Kirk a participé. Il y avait d'autres opinions très intéressantes, telles que l'utilisation de la méthode ReleaseComObject et de FinalReleaseComObject (ou quelque chose du genre). Désolé, je n'ai pas le lien sur moi en ce moment.
Certains ont même suggéré de libérer les IRows, mais beaucoup ont convenu qu'il était simplement plus facile de laisser GC les gérer directement.
Je ne libère aucun IGeometry. Quelqu'un a essayé ça?
J'utiliserai ESRI.ArcGIS.ADF.ComReleaser. Cela étant dit, je ne sais pas exactement quels objets d'arc utilisent un modèle de libération déterministe, mais je l'attache principalement à l'objet IServerContext car c'est le plus crucial.
using (ComReleaser comReleaser = new ComReleaser())
{
}
voici quelques informations que j'ai pu obtenir lors du sommet des développeurs esri 2011.
La grande liste dont je me souvenais était pour les objets singleton (qui sont deux sujets dans l'aide).
Il s'agit du lien de la rubrique Meilleures pratiques pour l'utilisation d'ArcObjects dans .NET "Libération des références COM": http://help.arcgis.com/en/sdk/10.0/arcobjects_net/conceptualhelp/index.html#/Releasing_COM_references/0001000004tm000000/
Et voici un article sur le blog de la géodatabase pour une discussion de quatre mètres qui contient une liste d'objets: http://blogs.esri.com/dev/blogs/geodatabase/archive/2010/05/18/what_2700_s‑up‑with ‑Comreleaser_3f00_.aspx
(enfin un article de blog avec un lien pour aider au cas où l'url ne fonctionnerait pas) http://blogs.esri.com/dev/blogs/geodatabase/archive/2008/12/18/using‑the‑comreleaser‑to‑manage -La-durée-de-vie-des-curseurs-en-.net.aspx
N'oubliez pas les objets IWorkspace. Au sommet des développeurs ESRI il y a quelques années, j'ai posé la question, et la réponse d'ESRI était des objets ICursor et IWorkspace.
les règles sont-elles différentes lorsque vous travaillez avec des objets serveur comme un curseur dans une SOI? J'essaie d'utiliser ComReleaser mais il échoue chaque fois qu'il se rapproche de la méthode dans mon code SOI