Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Do I need to release each object? Is some memory management handled for me?

ArcEngine 10, VS2010 C#

share|improve this question
up vote 17 down vote accepted

Most notably, always explicitly release cursors when you are done with them. I also release some enumeration objects which imply database access, for example IEnumRelationship you get from IRelationshipClass.GetRelationshipsForObject.

Also, when you create a lot of COM instances which are short-lived (especially in tight loops), it is also a good idea to release them explicitly.

There are also scenarios when is it advisable to release individual feature (row) references. For example, if you create a new geodatabase version, edit data, reconcile&post, attempts to delete the version afterwards might fail since there might be unreleased rows, which in turn keep reference to the version (workspace) you are trying to delete. Mostly, though, such scenarios are rare and you do not need to account for them in your day-to-day ArcObjects development. It would only make the code cluttered with extraneous cleanup, making it less maintainable.

It is also important to say when not to release .NET wrappers - never explicitly release RCW of ArcObjects which might be in use by any other managed code. One example of this - do not release IMap when in ArcMap. In general, do not try to release ArcObjects which you did not create.

share|improve this answer

For the most part .NET garbage collection works well. There are some cases in ArcObjects that do important work on desctructors and the non-deterministic nature of the .NET wrappers can cause issues. This help topic covers the primary cases to be concerned about and how to manage releases.

share|improve this answer

Always destroy:

  • ICursors
  • IEnums

Be careful to not destroy something that's being used somewhere else.

Today I read a interesting discussion on ESRIs website in which Kirk participated. There were other very interesting opinions, such as the use of ReleaseComObject method and the FinalReleaseComObject (or something the like). Sorry I don't have the link on me right now.

Some even suggested to release IRows, but many agreed that it's just easier to let GC handle them directly.

I never release any IGeometry's. Anyone tried that?

share|improve this answer

Don't forget IWorkspace objects. At the ESRI dev Summit a couple of years ago, I asked the question, and the answer from ESRI was ICursor and IWorkspace objects.

share|improve this answer
There is no point to releasing workspaces because they are cached by the workspace factory singletons. – Preston Nov 20 '13 at 23:58

I will use the ESRI.ArcGIS.ADF.ComReleaser. That being said I'm not exactly sure which arc objects use a deterministic release pattern but I mostly attach it to the IServerContext object since that is the most crucial.

using (ComReleaser comReleaser = new ComReleaser())


here's some information I was able to obtain at the 2011 esri Developer summit.

The big list I was remembering was for the singleton objects (which is two topics down in the help).

This is the link from the Best practices for using ArcObjects in .NET "Releasing COM references" topic:

And here is a post on the Geodatabase Blog to a fourm discussion that does contain a list of objects:‑up‑with‑comreleaser_3f00_.aspx

(lastly a blog post with a link to help in case the url didnt work)‑the‑comreleaser‑to‑manage‑the‑lifetime‑of‑cursors‑in‑.net.aspx

share|improve this answer
When working with IServerContext, more crucial (than to release its .NET RCW as ComReleaser does) is to call ReleaseContext on it. Best way is to wrap the context in a .NET class implementing IDisposable (and following the standard dispose pattern including implementing the finalizer) – Petr Krebs Apr 4 '11 at 18:55
@Petr yes releaseContext is huge and something I haven't overlooked but thanks for putting it in writing for everyone else. – Steve Apr 4 '11 at 21:26
I believe that ComReleaser is part of a 32bit assembly meaning that you won't be able to run ComReleaser in a 64bit process (e.g. ArcGIS Server). I was writing an SOE and got burned on this. – bcollins Jul 30 '13 at 14:36

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.