marshall... law and order

Hi there, I was curious to find out if COM compliant components in ArcObjects still exists in 9.2. Since the release of ArcGIS 8.x, COM has been the technology driving ArcObjects to run on Windows. ArcGIS Desktop needs this to run the Windows app. So with the advent of 9.2 and all the accompanying dotNET classes, I thought that COM is replaced. But not so... I found out.

The programming functionality of ArcObjects can now be accessed using 4 APIs: COM, .NET, Java and C++. The choice of which API to choose is not a simple one... it depends on a number of factors actually... the ArcGIS product that you are developing with, the end user functionality and development experience.

As I mentioned before, code running under the .NET Framework control is called managed code (read my blog on JIT). COM is a fine example of unmanaged code. So how does ArcObjects's COM object speak to .NET based application... well... its via a technology called COM Interop. For COM Interop to work, the Common Language Runtime (CLR) requires metadata for all the COM types. This means that the COM type definitions normally stored in type libraries need to be converted to .NET metadata. Once the metadata is available .NET clients can seamlessly create instances of COM types as though they were native .NET instances. ESRI provides primary interop assemblies for all the ArcObjects type libraries that are implemented with COM. The Interop API provides Runtime Callable Wrappers (RCW) to use COM Objects in .NET

Let me give an example in C#:
ESRI.ArcGIS.Geometry.Point pt = new ESRI.ArcGIS.Geometry.Point()

What happens when this code runs?? A Runtime Callable Wrapper object is defined instead of the actual COM object itself. When the object is instantiated (using the NEW keyword), the wrapper object creates the appropriate COM object. When you call the members of the object in .NET, the parameters of the method will be marshalled from the .NET process to COM process and the return value will be marshaled back. This is what happens behind the scenes in ArcObject ... for now.

Sounds complex?? Many times ArcObjects programmers don't realise this but when performance issues hits the roof we need to know why the memory allocation screws up sometimes. This could also explain why ArcGIS desktop is kinda slow for certain GIS processes. However, this is minimal impact considering the vast advantages of using ArcObjects and .NET programming to create cool and exciting apps.