Craig, Thanks for your explanation. I am however, confused by the following article written by Shannon Pahl, a Microsoft COM+ program manager. This article seems to suggest that if ContextUtil() is called from an non- Transacted object that's part of a call chain initiated by a Transacted object, it may cause unexpected behaviour in future .NET versions!!!
Frankly, I think it makes no sense unless the call involves a context switch, but thought you might want to comment on it (the last line in the paragraph is especially interesting): <http://www.gotdotnet.com/team/xmlentsvcs/espaper.aspx> Contexts (excerpted from link) The class ContextUtil is used to access the associated COM+ object context and its properties. This provides similar functionality as the object returned by CoGetObjectContext in unmanaged code. The managed object context associated with a serviced component serves a different purpose than the associated unmanaged object context. This is manifested by writing three managed objects, one with Transactions required (acting as the root), the other two not deriving from serviced component (acting as child objects exemplifying context-agile managed objects). The non serviced components will behave as if they were serviced components with Transactions supported, that is, they can make calls to resource managers and use ContextUtil.SetAbort if needed. When the root object gets created, the associated unmanaged context is created and associated with the current thread. When a call to the child objects is made, since they are not associated with an unmanaged context, no COM+ context change is needed, hence the thread still maintains the roots unmanaged context id. When a child object calls on resource managers, the resource managers will in turn extract the unmanaged context from the thread executing the child object, which is the root objects unmanaged context. Relying on this is dangerous and in future versions the unmanaged context may merge with the managed context and therefore the child objects will be associated with a potentially different managed context; the resource managers will not pick up the root objects context. Therefore, upgrading to a new version of .NET could break code that depends on this type of behavior. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
