. Net object and COM Object

Original article: http://www.gispower.org/article/arcgis/ao/2008/727/08727194926C5JHDD0AAE64CJCF6632_3.html

Most of the content here comes from the msdn library for Visual Studio 2005. Because ArcObjects is written in C ++, to be developed on. NET, all its components exist in the form of COM .. All things on net are hosted, while com is not hosted. The interaction between COM and C # is implemented through the wrapper. There are two types: RCW (runtime callable wrapper) the Runtime Library callable packaging and CCW (COM collable wrapper) com callable packaging .. Next, let's talk about the differences between COM objects and. Net objects. This is very important.

Com differs from the. NET Framework object model in the following important aspects:
1. the COM Object client must manage the lifetime of these objects; the Common Language Runtime Library manages the lifetime of each object in its environment.
2. the COM Object client sends a request to the interface that provides the service and retrieves the interface pointer to check whether the service is available .. The client of the net object can use reflection to obtain the description of the object function ..
3. Net objects reside in the memory managed by the. NET Framework execution environment. To improve performance, the execution environment can move the object back and forth in the memory and update any reference to the object to be moved. After obtaining the pointer to an object, the unmanaged client will depend on the object to keep its position unchanged. These clients do not have a mechanism to process objects with unfixed locations.
To overcome these differences, the Runtime Library provides packaging classes so that hosted and unmanaged clients think they are calling objects in their own environments. Every time a hosting client calls a method on a COM object, the runtime creates an RCW. One of the functions of RCW is to extract differences between hosted and unmanaged reference mechanisms. The runtime will also create a CCW to reverse this process, so that the COM Client can seamlessly call methods on. NET objects. As shown in, the nature of the called Code determines the packaging class created by the Runtime Library.
Com package Overview

In most cases, the standard RCW or CCW generated by the Runtime Library will provide sufficient sending for calls that span the boundaries between COM and. NET Framework. With custom properties, You can selectively adjust how the runtime represents hosted and unmanaged code. For more details about the communication between managed and unmanaged systems, that is, the topic platform call and the com InterOP model, see the relevant content in msdn library for Visual Studio 2005.
Next, let's talk about why I always prefer to use interface types instead of classes to declare new objects when I use C # For ArcObjects programming and when I create an object or perform type conversion.
When you create a new COM Object in. net via InterOP, you get a reference to your object that is wrapped in a stronugly typed runtime callable wrapper (RCW ). a rcw is a wrapper that can hold a reference to a COM object inside. NET application. the meaning of this passage is very simple: in. all COM objects created in. NET are completed through RCW and only one wrapper is created for each COM Object. See the Code:
ESRI. ArcGIS. display. isimplemarkersymbol sym = new ESRI. ArcGIS. display. simplemarkersymbolclass ();
Debug. writeline (sym. GetType (). fullname );
The result is as expected: As you might failed CT; the variable holds a reference to the isimplemarkersymbol interface of the simplemarkersymbolclass RCW.
But the following situations are different, although it looks similar:
ESRI. ArcGIS. display. isimplemarkersymbol sym = rend. symbol as ESRI. ArcGIS. display. isimplemarkersymbol;
Debug. writeline (sym. GetType (). fullname );
The results show that you may find it strange that the sym type is system. _ comobject.
What type is this? In fact, this is the package class that can be used to represent any COM Object: This is a class internal to. NET framework that can be used to hold a reference to any kind of COM object; its purpose is to act as the RCW for an unknown type of COM object. note that the metadata contained in the General Com package is very limited. If you want to create a certain class instance, you must ensure that you can obtain the metadata of the class. Otherwise, you will always encounter an inexplicable error when creating the ArcObjects object. This error is especially common when the keyword "as" is used for type conversion.
For example, ESRI. ArcGIS. display. simplemarkersymbolclass sym2 = sym as ESRI. ArcGIS. display. simplemarkersymbolclass; // Error
ESRI. ArcGIS. display. isimplemarkersymbol sym3 = sym as ESRI. ArcGIS. display. isimplemarkersymbol; // Yes
The reason is from system. _ comobject, The sym variable may have been used through system. _ comobject gets reference to a COM object, so there is not enough metadata to be converted into other strong type wrapper.
The following is a clear explanation: however, as the system. _ comobject class is specifically designed to work with COM objects, it is always able to perform a Qi to any COM interfaces that are implemented by an object. therefore, casting to specific interfaces (as long as they are implemented on the object) will be successful.