COM on Marko Apfel

Interop effects by resolving and instantiating types with ArcObjects

Fri, 25 Nov 2011 14:10:00 +0100

Problem

this code does not work

Type t = typeof(ESRI.ArcGIS.Framework.AppRefClass);
System.Object obj = Activator.CreateInstance(t);

but yet this code

Type t = Type.GetTypeFromCLSID(typeof(ESRI.ArcGIS.Framework.AppRefClass).GUID);
System.Object obj = Activator.CreateInstance(t);

Reason

In the first variant the runtime tries to cast to AppRefClass. This is not possible.

And in the second one, the runtime does not knows anything about AppRefClass. So it leave it as IUnknown.

"Failure has occurred while loading a type."

Fri, 28 Oct 2011 12:08:00 +0200

Motivation

During programming suddenly this error (Failure has occurred while loading a type) was thrown by accessing a artifact of a referenced library.

In such cases I take the assembly fusion logger fuslogvw to search for problems of loading assemblies. Sometimes an old version from a not expected folder is binded. But all bindings were correct.

Calling esriRegasm manually (outside an ArcGIS-installation)

Tue, 26 Apr 2011 20:53:00 +0200

Since ArcGIS 10 during the Visual Studio build an additional target with the execution of a program named esriRegasm is called. Amongst other things this program adds the COM-categories in the registry.

Set ApartmentState for ArcObjects-logic in separate threads

Wed, 08 Sep 2010 10:54:00 +0200

Problem context

We use a backgroundworker to load .MXD documents from several places of the system and extract meta data and thumbnails which a GUI component shows in an asynchronous way.

The unit tests for this logic throws an exception during the access the thumbnail:

Verwenden von partiellen Klassen für COM-Belange

Mon, 12 Jul 2010 15:16:00 +0200

Motivation

Schon im Whitepaper „Auszeichnung von COM-Kategorien an .NET-Klassen mittels Attributen und deren Verwendung für Setup-Builds“ [1] habe ich deutlich gemacht warum das Verwenden von COM-Registrierungsfunktionen ein suboptimales Programmierpattern ist. Knackpunkt sind die Verstöße gegen SOC (separation of concerns) [2] und SRP (single responsibility principle) [3].

Catching COM-Exceptions from ArcObjects

Tue, 20 Oct 2009 14:36:00 +0200

to catch the COM-Exception in own applications thrown from the underlaying ArcObjects-Library could be done with:

catch (COMException ComEx)
{
 Console.WriteLine(string.Format("MyCode errored: {0}, Error Code: {1}",
 ComEx.Message, ComEx.ErrorCode));
}

the special error constants could be found under: