tags:

views:

57

answers:

1

I am using reading the documentation for app domains in .net 3.5 and came across SandboxInterop. The docs says

Gets or sets a value that indicates whether interface caching is disabled for interop calls in the application domain, so that a QueryInterface is performed on each call.

But why would I ever wish to disable the caching of QueryInterface?

(A quick google does not find anything that explains the way?)

+1  A: 

In typical operation, there usually is little reason to worry about QueryInterface calls being cached.

However, other parties may create components where the number of outstanding interfaces is tied to the operation of the component. In addition, there are also outliers where the interface received from a COM object has an implementation that may make it tougher to control the lifetime of the object.

For example, components written in ATL may be created with tearoff interfaces. These tearoffs are not available in the binary layout of the main object, and are typically implemented on another hidden object that coordinates with its parent. Since a successful QueryInterface call implicitly counts as an AddRef call, the lifetime of the tearoff provider may be extended past its intended release if the interface reference is cached. Also, there may also be a case where an object only provides one tearoff of a particular interface with the intent that there is only one consumer at a time through that interface. A cached copy could violate that behavior if two consumers are issued the same copy when the intent is for the second request to fail.

Finally, a more likely scenario is the possibility that each QueryInterface call is being tracked for debugging or logging purposes. Being able to turn off caching may allow someone to diagnose issues where occurrences could be delayed with it on.

Here are some links on tearoff interfaces for your reference.

ATL Tear-Off Interfaces @ CodeGuru

CComTearOffObject Class @ MSDN

meklarian
so it is for debugging and when com object don't really keep to the com spec. However way is it at the level of a AppDomain, not per com interface?
Ian Ringrose
Yes, well, it should apply to all instances of COM objects known within an AppDomain.It might be more succinct to say that caching is not a behavior that is expected as a result of using COM objects, so not having this option might leave some implementations in trouble due to side effects.
meklarian