Pedram Rezaei's Ramblings : COM

AzMan Data Store through COM Interop

pedramr — Thu, 04 Oct 2007 11:42:00 GMT

If you have an ASP.NET application, you can use the AuthorizationStoreRoleProvider which adheres to the Role Provider model expected by ASP.NET and retrieves role information from Microsoft Authorization Manager (AzMan).

AzMan itself is a COM based application and all communications with the store occur through COM Introp exposed in Microsoft.Interop.Security.AzRoles namespace. If you decide not to use the AuthorizationStoreRoleProvider (for instance if you are in a Windows Application), you can directly use the COM Introp layer provided by Microsoft. See here for a list of wrapper methods and objects.

When directly using these wrappers, you need to ensure that you always release the COM objects that are no longer required. For instance when creating and submitting a new Role in AzMan then you must use Marshal. FinalReleaseComObject or Marshal. ReleaseComObject to release the COM object:

IAzRole role = app.CreateRole("Test", null);

role.Submit(0, null);

Marshal.FinalReleaseComObject(role);

And here is another example:

IAzRole role = app.OpenRole("Test", null);

app.DeleteRole("Test", null);

Marshal.FinalReleaseComObject(role);

If you don’t release the COM object, the code snippet below may throw a “Cannot create a file when that file already exists. (Exception from HRESULT: 0x800700B7)” COMException or some other unexpected exceptions:

app.CreateRole("Test", null);

app.DeleteRole("Test", null);

app.CreateRole("Test", null);

The above is also applied to enumerators – only on some versions of Windows. Many of the enumerators automatically generated by the wrapper library internally use COM objects which need to be released. For instance the code below does not release all COM objects:

foreach (IAzRole role in app.Roles)

{

app.DeleteRole(role.Name, null);

Marshal.FinalReleaseComObject(role);

}

What you really want is the following:

IEnumerable roles = app.Roles;

IEnumerator enumerator = roles.GetEnumerator();

try

{

while (enumerator.MoveNext())

{

IAzRole role = enumerator.Current as IAzRole;

try

{

app.DeleteRole(role.Name, null);

}

finally

{

Marshal.FinalReleaseComObject(role);

}

finally

{

ICustomAdapter adapter = (ICustomAdapter)enumerator;

Marshal.ReleaseComObject(adapter.GetUnderlyingObject());

Marshal.FinalReleaseComObject(roles);

}

As you can see the enumerator also internally uses a COM object which may not be released automatically and should be released manually. This underlying COM object is accessible through:

((ICustomAdapter)enumerator).GetUnderlyingObject()

ThreadAbortException and Unmanaged Code

pedramr — Tue, 02 Oct 2007 15:04:00 GMT

As you are probably aware Thread.Abort() raises a ThreadAbortException in the thread on which it is invoked, to begin the process of terminating the thread.

Please note that if Abort is called on a managed thread while it is executing unmanaged code, a ThreadAbortException is not thrown until the thread returns to managed code. That is also true when performing a COM Interop or P-Invoke. However if you have a ServicedComponent, the exception is received by the thread inside the component as expected. For instance if you are in an ASP.NET application and a timeout is occurred (timeout is communicated in terms of a ThreadAbortException) the exception is raised inside the component.

.NET ServicedComponents and STA Apartment

pedramr — Sun, 05 Aug 2007 17:52:00 GMT

A major issue with running all COM components using STA threads is that the thread which calls CoInitializeEx must be the only thread executing method invocations on that COM instance. Now assume a scenario in which the STA thread is busy performing other activities. In those scenarios you will receive an exception similar to the following and the way around that is to somehow ensure that the message loop on the STA thread is being pumped frequently. In other words anything causing a delay in this process may be an issue and you may receive an exception similar to the following:

“ContextSwitchDeadlock was detected

The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.”

Here is an example of the problem (ComInstance is a ServicedComponent):

Thread t = new Thread(

delegate(object a)

{

ComInstance o = new ComInstance();

Thread tt = new Thread(

delegate(object q)

{

// A deadlock will be detected here
o.ComMethodCall();

});

tt.Start();

while (true)

{

// keep the thread alive

// must pump the message loop

// ...

}

});

t.SetApartmentState(ApartmentState.STA);

t.Start();
Console.ReadLine();

.NET Thread Apartment and COM Interop

pedramr — Sun, 05 Aug 2007 17:51:00 GMT

Before a thread can call into a COM object it has to define its apartment by declaring whether it will enter a single-threaded apartment (STA) or a multi-threaded apartment (MTA). STA client threads call CoInitialize(NULL) or CoInitializeEx(0, COINIT_APARTMENTTHREADED) to enter an STA apartment and MTA threads call CoInitializeEx(0, COINIT_MULTITHREADED) to enter an MTA.

When calling a COM component, it is important to ensure that the threading models of the component and the client are compatible. For instance VB6 components insist on using the STA threading model. With an STA component, a message queue is associated with a hidden window and requests are queued and a single thread in STA apartment processes the messages synchronously of the queue. This ensures that access to the component is synchronised. However, if the client uses an MTA threading model to instantiate this STA component, not only a thread switch between the MTA and the STA thread needs to occur but also an apartment marshalling is required which can be an expensive process. Therefore it is recommended to use compatible threading models to ensure that apartment threaded component instance is created in the client's apartment.

Similarly, in the .NET managed world, you have the option of allowing the calling thread in the managed space declare its apartment affinity. For example, it is possible to associate a thread in .NET to the single-threaded apartment. This is usually the recommended approach when calling legacy VB6 COM.

Threads inside .NET’s thread pool are associated to the multi-threaded apartment (MTA) therefore requiring a thread switch and an apartment marshalling when calling VB6 components. It is recommended to use dedicated threads with ApartmentState property set to STA when calling into an STA component (use SetApartmentState method).