Release of several common unmanaged objects in. NET + AE Development

Original article: http://www.gispower.org/article/arcgis/ao/2008/422/08422155439C03H5EFI9CE4H8CGDFF_3.html

We know that. NET provides two methods for memory management: managed object management and non-managed object management. The memory management we usually understand is GC (garbage collection). Although GC manages managed heaps, this gives us the opportunity to free up from the problems of traditional locks such as memory leaks and focus on the logic of the program. However, handing over everything to the GC may sometimes compromise the program's efficiency, or even cause errors.

Why is this happening? The problem is that the GC performance is a little unsatisfactory for unmanaged resources (file handles) or bitmap objects that require special attention (this sentence may not be correct, because Microsoft designed GC to manage managed objects ). How to effectively use GC for memory management and how to optimize program performance is not covered in this article. The purpose of this article is how to release unmanaged objects during AE development.

1. aouninitialize. shutdown.

This is often the case when we exit the AE application: "The instruction x references memory at X. The memory cocould not be read ". The main cause of this error is that the COM Object (an unmanaged object) is not released. When we end the process that uses it, it stops us from releasing it normally, the priority of release is higher than that of the process currently using it. That is to say, before a process is released, it must be released first.

After understanding the above principles, the solution to this problem is very simple. We only need to call ESRI before the application exits. arcGIS. ADF. comsupport. aouninitialize. the shutdown () method is used to release the unmanaged object. (versions earlier than 9.2 of aouninitialize are not in ESRI. arcGIS. ADF. in the comsupport namespace, note that ).

Ii. Marshal. releasecomobject

In. NET development, references to COM objects are mainly implemented through the RCW (runtime callable wrappers) mechanism (somewhat similar to the proxy mode ). GC is a little powerless for the release of COM objects. Therefore, the resources occupied by COM objects must be released in the program. Otherwise, unexpected errors may occur. For example, if you repeatedly open Geodatabase cursors from the personal Geodatabase but do not release it in time, "No more tables can be opened. "In other cases, you may find that the COM object is still referenced in the memory when the application exits. For example, if stylegallery does not show release, an error is thrown when the application exits.

1. Releasing stylegallery:

Private void myfunction ()
{
Istylegallery stycls = new stylegalleryclass () as istylegallery;
Int refsleft = 0;
Do {
Refsleft = marshal. releasecomobject (stycls );
}
While (refsleft> 0 );
}

2. Releasing Geodatabase cursors
For (INTI = 1; I <2500; I ++ ){
Iqueryfilter Qu = new queryfilterclass ();
Qu. whereclause = @ "Area =" + I. tostring ();
Ifeaturecursor featcursor = featclass. Search (qu, true );
// Use the feature cursor as required
System. runtime. interopservices. Marshal. releasecomobject (featcursor );

}

3. Releasing webobject (ArcGIS Server)
Private void dosomthing_click (Object sender, system. eventargs E)
{
Using (webobject webobj = new webobject ())
{
Serverconnection serverconn = new serverconnection ("Doug", true );
Iserverobjectmanager som = serverconn. serverobjectmanager;
Iservercontext CTX = som. createservercontext ("Yellowstone", "mapserver ");
Imapserver mapsrv = CTX. serverobject asimapserver;
Imapserverobjects Mapo = mapsrv as imapserverobjects;
IMAP map = Mapo. get_map (mapsrv. defaultmapname );
Ifeaturelayer flayer = map. get_layer (0) as ifeaturelayer;
Ifeatureclass fclass = flayer. featureclass;
Ifeaturecursor fcursor = fclass. Search (null, true );
Webobj. managelifetime (fcursor );
Ifeature F = NULL;
While (F = fcursor. nextfeature ())! = NULL)
{
}
CTX. releasecontext ();
}
}

4. Releasing ienumstylegalleryitem (some enumeration interface objects need to be released)

 

3. When should I release an unmanaged object?
This issue is very important. When we are sure that we will not call unmanaged object Resources after release, we can call system. runtime. interopservices. marshal. the releasecomobject () method is explicitly released. Otherwise, a new error is thrown.
Summary: This article briefly lists several common releases of unmanaged objects in AE development for your reference. Some aspects are not detailed enough. You can obtain detailed information from the help of ArcGIS Engine.

References:
1. Memory Management in. net

2. ArcGIS Engine development help