Odpowiedzi:
Co najważniejsze, zawsze jawnie zwalniaj kursory, gdy z nimi skończysz. Zwalniam również niektóre obiekty wyliczeniowe, które implikują dostęp do bazy danych, na przykład IEnumRelationship, który otrzymujesz z IRelationshipClass.GetRelationshipsForObject .
Ponadto, gdy tworzysz wiele instancji COM, które są krótkotrwałe (szczególnie w ciasnych pętlach), dobrym pomysłem jest ich jawne zwolnienie.
Istnieją również scenariusze, w których wskazane jest zwolnienie referencji poszczególnych funkcji (wierszy). Na przykład, jeśli utworzysz nową wersję geobazy, edytujesz dane, uzgadniasz i publikujesz, próby późniejszego usunięcia wersji mogą się nie powieść, ponieważ mogą istnieć niepublikowane wiersze, które z kolei zachowują odniesienie do wersji (obszaru roboczego), którą próbujesz usunąć. Przeważnie jednak takie scenariusze są rzadkie i nie trzeba ich uwzględniać w codziennym rozwoju ArcObjects. Spowodowałoby to jedynie zaśmiecenie kodu obcym czyszczeniem, co utrudniłoby jego utrzymanie.
Ważne jest również, aby powiedzieć, kiedy nie należy wypuszczać opakowań .NET - nigdy nie należy jawnie wypuszczać RCW ArcObjects, które mogą być używane przez jakikolwiek inny zarządzany kod. Jeden przykład tego - nie zwalniaj IMap w ArcMap. Zasadniczo nie próbuj wypuszczać ArcObjectów, których nie utworzyłeś.
W większości śmieciowanie .NET działa dobrze. Istnieją pewne przypadki w ArcObjects, które wykonują ważną pracę na desctructors i niedeterministyczny charakter owijania .NET może powodować problemy. Ten temat pomocy obejmuje podstawowe przypadki, którymi należy się martwić oraz sposoby zarządzania wydaniami.
Zawsze niszcz:
Uważaj, aby nie zniszczyć czegoś, co jest używane gdzie indziej.
Dzisiaj przeczytałem ciekawą dyskusję na stronie internetowej ESRI, w której uczestniczył Kirk. Były też inne bardzo interesujące opinie, takie jak użycie metody ReleaseComObject i FinalReleaseComObject (lub coś podobnego). Przepraszam, nie mam teraz linku do mnie.
Niektórzy nawet sugerowali wydanie IRows, ale wielu zgodziło się, że łatwiej jest pozwolić GC bezpośrednio na ich obsługę.
Nigdy nie wypuszczam żadnych IGeometrii. Ktoś tego próbował?
Użyję ESRI.ArcGIS.ADF.ComReleaser. Biorąc to pod uwagę, nie jestem do końca pewien, które obiekty łukowe używają deterministycznego wzorca uwalniania, ale w większości dołączam go do obiektu IServerContext, ponieważ jest to najważniejsze.
using (ComReleaser comReleaser = new ComReleaser())
{
}
oto kilka informacji, które udało mi się uzyskać na szczycie programistów esri w 2011 roku.
Duża lista, którą zapamiętałem, dotyczyła obiektów singletonowych (czyli dwa tematy w dalszej części pomocy).
To jest link do najlepszych praktyk dotyczących używania ArcObjects w .NET „Wydawanie odniesień COM”: http://help.arcgis.com/en/sdk/10.0/arcobjects_net/conceptualhelp/index.html#/Releasing_COM_references/0001000004tm000000/
A tutaj jest post na blogu Geodatabase do czteromilionowej dyskusji, która zawiera listę obiektów: http://blogs.esri.com/dev/blogs/geodatabase/archive/2010/05/18/what_2700_s‑up‑with ‑Comreleaser_3f00_.aspx
(na koniec post na blogu z linkiem do pomocy w przypadku, gdyby adres URL nie zadziałał) http://blogs.esri.com/dev/blogs/geodatabase/archive/2008/12/18/using‑the‑comreleaser‑to‑manage -The-lifetime-of-cursors-in-.net.aspx
Nie zapomnij o obiektach IWorkspace. Kilka lat temu na szczycie deweloperów ESRI zadałem pytanie, a odpowiedzią ESRI były obiekty ICursor i IWorkspace.
czy reguły różnią się podczas pracy z obiektami serwera, takimi jak kursor w SOI? Próbuję użyć ComReleaser, ale kończy się niepowodzeniem za każdym razem, gdy zbliży się do metody w moim kodzie SOI