BUG: Calling GetType or GetHashCode on a remoting object destroys the CallContext (320347)



The information in this article 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 Edition
  • Microsoft Visual Studio .NET (2002), Enterprise Developer Edition
  • Microsoft Visual Studio .NET (2002), Academic Edition
  • Microsoft Visual Studio .NET (2003), Professional Edition
  • Microsoft Visual Studio .NET (2003), Enterprise Architect Edition
  • Microsoft Visual Studio .NET (2003), Enterprise Developer Edition
  • 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 "Applies to" section.

MORE INFORMATION

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 ("Lib1.MBRClass,Lib1"),
	"http://localhost:8080/someMBRClass") ;
MBRClass RemObj = new MBRClass () ;

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

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

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

Modification Type:MinorLast Reviewed:9/13/2005
Keywords:kbvs2002sp1sweep kbbug kbnofix kbRemoting KB320347