Microsoft KB Archive/320347

= BUG: Calling GetType or GetHashCode on a remoting object destroys the CallContext =

Article ID: 320347

Article Last Modified on 2/23/2007

-

APPLIES TO


 * Microsoft .NET Framework 1.0
 * Microsoft .NET Framework 1.1
 * Microsoft Visual Studio .NET 2002 Professional Edition
 * Microsoft Visual Studio .NET 2002 Enterprise Architect
 * Microsoft Visual Studio .NET 2002 Enterprise Developer
 * Microsoft Visual Studio .NET 2002 Academic Edition
 * Microsoft Visual Studio .NET 2003 Professional Edition
 * Microsoft Visual Studio .NET 2003 Enterprise Architect
 * Microsoft Visual Studio .NET 2003 Enterprise Developer
 * Microsoft Visual Studio .NET 2003 Academic Edition

-



This article was previously published under Q320347



SYMPTOMS
When you call the GetType method or the GetHashCode method on a remoted object, remotable items in the CallContext object are destroyed.



CAUSE
You can use the CallContext object to send information along a managed call path. The object provides a set of properties that are carried with the execution code path, so that the call can maintain and access persisted data. You can place any object type in the call context. Also, you can make CallContext items flow over .NET Remoting channels. These objects flow to and from the Remoting client and the Remoting server. To make CallContext object types remotable, the objects must be serializable and must implement the ILogicalThreadAffinitive interface.

Remoted objects are objects that are configured to be called by using .NET Remoting. When you call the GetType method and the GetHashCode method on Remoted objects in the code path, the remotable call context items are deleted because the GetType and the GetHashCode method do not carry over the remotable CallContext of the incoming message, which results in a null CallContext. Because CallContext is null, the remotable CallContext data is lost. Non-remotable CallContext items are not lost.



RESOLUTION
To work around this issue, replace the default GetType method and the default GetHashCode method with your own implementation in your Remote Object class. For example, the following C# definition of GetType corrects the problem: public new Type GetType {   return base.GetType; } This method overrides the base GetType method and prevents the error.



STATUS
Microsoft has confirmed that this is a bug in the Microsoft products that are listed in the &quot;Applies to&quot; section.



Steps to Reproduce the Behavior
To reproduce the behavior, set a remotable object in the CallContext object in a .NET Remoting client, and then make a remoted call to the GetHashCode method or the GetType method. The following C# sample code demonstrates this.

Object to be remoted by using the CallContext object: [Serializable] public class CallCtxObj : ILogicalThreadAffinative {   public string CtxString ; public CallCtxObj(string s) {CtxString = s ;} public CallCtxObj {CtxString = null ;} } Remoting client that uses the previous object: // Configure an object type to be called by using .NET Remoting. RemotingConfiguration.RegisterWellKnownClientType(   Type.GetType (&quot;Lib1.MBRClass,Lib1&quot;),    &quot;http://localhost:8080/someMBRClass&quot;) ; MBRClass RemObj = new MBRClass ;

// Create an instance of the object, and then put the object in the CallContext. CallCtxObj cco = new CallCtxObj(&quot;Client String&quot;) ; CallContext.SetData(&quot;CallData&quot;, cco);

// Call GetHashCode or GetType. int i = RemObj.GetHashCode ;

// CallContext returns null when you try to retrieve the CallContext object. cco = (CallCtxObj) CallContext.GetData (&quot;CallData&quot;) ; // cco is  null after this call.

Keywords: kbvs2002sp1sweep kbbug kbnofix kbremoting KB320347

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.