Risposte:
In particolare, rilascia sempre in modo esplicito i cursori quando hai finito con loro. Rilascio anche alcuni oggetti di enumerazione che implicano l'accesso al database, ad esempio IEnumRelationship ottenuto da IRelationshipClass.GetRelationshipsForObject .
Inoltre, quando si creano molte istanze COM di breve durata (specialmente in loop ristretti), è anche consigliabile rilasciarle in modo esplicito.
Esistono anche scenari in cui è consigliabile rilasciare riferimenti a singole funzioni (righe). Ad esempio, se si crea una nuova versione del geodatabase, si modificano i dati, si riconciliano e si postano, i tentativi di eliminare la versione in seguito potrebbero non riuscire poiché potrebbero esserci righe non rilasciate, che a loro volta mantengono il riferimento alla versione (spazio di lavoro) che si sta tentando di eliminare. Principalmente, tuttavia, tali scenari sono rari e non è necessario tenerne conto nello sviluppo quotidiano di ArcObjects. Renderebbe il codice ingombro solo di pulizia estranea, rendendolo meno gestibile.
È anche importante dire quando non rilasciare i wrapper .NET - non rilasciare mai esplicitamente RCW di ArcObjects che potrebbe essere utilizzato da qualsiasi altro codice gestito. Un esempio di ciò: non rilasciare IMap in ArcMap. In generale, non provare a rilasciare ArcObjects che non è stato creato.
Per la maggior parte, la garbage collection di .NET funziona bene. Ci sono alcuni casi in ArcObjects che svolgono un lavoro importante sui descrittori e la natura non deterministica dei wrapper .NET può causare problemi. Questo argomento della guida tratta i casi principali di cui preoccuparsi e come gestire le versioni.
Distruggi sempre:
Fai attenzione a non distruggere qualcosa che viene utilizzato da qualche altra parte.
Oggi ho letto un'interessante discussione sul sito web dell'ESRI a cui Kirk ha partecipato. C'erano altre opinioni molto interessanti, come l'uso del metodo ReleaseComObject e FinalReleaseComObject (o qualcosa del genere). Mi dispiace non ho il link su di me in questo momento.
Alcuni hanno persino suggerito di rilasciare IRows, ma molti hanno concordato che è più semplice lasciare che GC li gestisca direttamente.
Non ho mai rilasciato IGeometry. Qualcuno l'ha provato?
Userò ESRI.ArcGIS.ADF.ComReleaser. Detto questo, non sono esattamente sicuro di quali oggetti arco utilizzino un modello di rilascio deterministico, ma perlopiù lo collego all'oggetto IServerContext, poiché questo è il più cruciale.
using (ComReleaser comReleaser = new ComReleaser())
{
}
ecco alcune informazioni che sono stato in grado di ottenere al summit Developer 2011 di esri.
La grande lista che stavo ricordando era per gli oggetti singleton (che sono due argomenti in fondo alla guida).
Questo è il collegamento dalle best practice per l'utilizzo di ArcObjects nell'argomento "Rilascio di riferimenti COM" .NET: http://help.arcgis.com/en/sdk/10.0/arcobjects_net/conceptualhelp/index.html#/Releasing_COM_references/0001000004tm000000/
Ed ecco un post sul blog di Geodatabase a una discussione di quattro metri che contiene un elenco di oggetti: http://blogs.esri.com/dev/blogs/geodatabase/archive/2010/05/18/what_2700_s‑up-with -comreleaser_3f00_.aspx
(infine un post sul blog con un link per aiutare nel caso in cui l'URL non funzionasse) http://blogs.esri.com/dev/blogs/geodatabase/archive/2008/12/18/using‑the‑comreleaser‑to‑manage -la-vita-di-cursori-in-.net.aspx
Non dimenticare gli oggetti IWorkspace. Al Summit degli sviluppatori ESRI un paio di anni fa, ho posto la domanda e la risposta di ESRI è stata ICursor e oggetti IWorkspace.
le regole sono diverse quando si lavora con oggetti server come un cursore in una SOI? Sto cercando di utilizzare ComReleaser ma non riesce ogni volta che si avvicina al metodo nel mio codice SOI