Respuestas:
En particular, siempre suelte los cursores explícitamente cuando haya terminado con ellos. También publico algunos objetos de enumeración que implican acceso a la base de datos, por ejemplo, IEnumRelationship que obtienes de IRelationshipClass.GetRelationshipsForObject .
Además, cuando crea muchas instancias COM que son de corta duración (especialmente en bucles cerrados), también es una buena idea liberarlas explícitamente.
También hay escenarios en los que es aconsejable liberar referencias de características individuales (filas). Por ejemplo, si crea una nueva versión de geodatabase, edita datos, concilia y publica, los intentos de eliminar la versión después pueden fallar ya que puede haber filas inéditas, que a su vez mantienen la referencia a la versión (espacio de trabajo) que está tratando de eliminar. Sin embargo, en su mayoría, tales escenarios son raros y no es necesario que los tenga en cuenta en su desarrollo diario de ArcObjects. Solo haría que el código estuviera abarrotado de limpieza extraña, lo que lo haría menos mantenible.
También es importante decir cuándo no lanzar envoltorios .NET: nunca publique explícitamente RCW de ArcObjects que pueda estar en uso por cualquier otro código administrado. Un ejemplo de esto: no libere IMap cuando se encuentre en ArcMap. En general, no intente liberar ArcObjects que no creó.
En su mayor parte, la recolección de basura .NET funciona bien. Hay algunos casos en ArcObjects que hacen un trabajo importante en desctructores y la naturaleza no determinista de los envoltorios .NET puede causar problemas. Este tema de ayuda cubre los casos principales por los que debe preocuparse y cómo administrar las versiones.
Siempre destruye:
Tenga cuidado de no destruir algo que se está utilizando en otro lugar.
Hoy leí una discusión interesante en el sitio web de ESRI en la que participó Kirk. Hubo otras opiniones muy interesantes, como el uso del método ReleaseComObject y FinalReleaseComObject (o algo similar). Lo siento, no tengo el enlace en este momento.
Algunos incluso sugirieron liberar IRows, pero muchos coincidieron en que es más fácil dejar que GC los maneje directamente.
Nunca lanzo ningún IGeometry. Alguien ha intentado eso?
Usaré el ESRI.ArcGIS.ADF.ComReleaser. Dicho esto, no estoy exactamente seguro de qué objetos de arco usan un patrón de liberación determinista, pero principalmente lo adjunto al objeto IServerContext, ya que es el más crucial.
using (ComReleaser comReleaser = new ComReleaser())
{
}
Aquí hay información que pude obtener en la cumbre de desarrolladores de esri 2011.
La gran lista que recordaba era para los objetos singleton (que son dos temas en la ayuda).
Este es el enlace de las Mejores prácticas para usar ArcObjects en el tema "Liberación de referencias COM" .NET: http://help.arcgis.com/en/sdk/10.0/arcobjects_net/conceptualhelp/index.html#/Releasing_COM_references/0001000004tm000000/
Y aquí hay una publicación en el Blog de Geodatabase en una discusión de cuatro meses que contiene una lista de objetos: http://blogs.esri.com/dev/blogs/geodatabase/archive/2010/05/18/what_2700_s‑up‑with ‑Comreleaser_3f00_.aspx
(por último, una publicación de blog con un enlace para ayudar en caso de que la url no funcione) http://blogs.esri.com/dev/blogs/geodatabase/archive/2008/12/18/using‑the‑comreleaser‑to‑manage -La-vida-de-cursores-en-.net.aspx
No olvide los objetos de IWorkspace. En la Cumbre de desarrolladores de ESRI hace un par de años, hice la pregunta, y la respuesta de ESRI fueron los objetos ICursor e IWorkspace.
¿Son diferentes las reglas cuando se trabaja con objetos de servidor como un cursor en un SOI? Estoy tratando de usar ComReleaser pero falla cada vez que se acerca al método en mi código SOI