FIX: CallContext objects are lost when you create a new serviced component (319177)
The information in this article applies to:
- Microsoft .NET Framework Class Libraries 1.0
- Microsoft Visual Studio .NET (2002), Professional Edition
- Microsoft Enterprise Services (included with the .NET Framework) 1.0
This article was previously published under Q319177 SYMPTOMS If you set CallContext objects before you create an instance of a serviced component in
a client application, you may lose the CallContext objects after you create the object instance. CAUSE This problem occurs if the objects that you place in the CallContext derive from the ILogicalThreadAffinative interface. If you place these objects in the CallContext (by using the CallContext.SetData method) and then create an instance of a ServicedComponent object, the CallContext.GetData method for those objects returns null. RESOLUTIONTo resolve this problem, obtain the
latest service pack for Microsoft .NET Framework. For additional information,
click the following article number to view the article in the Microsoft
Knowledge Base: 318836 INFO: How to Obtain the Latest .NET Framework Service Pack
WORKAROUND To work around this problem, use one of the following methods:
- If you only need to use CallContext items locally in your application, do not derive these items from
ILogicalThreadAffinative.
NOTE: The remoting system does not pass these objects across
AppDomains. - If you want to use remoting servers with ServicedComponent objects, and if you want to flow CallContext to them, you must create an instance of your ServicedComponent objects before you place those items in the CallContext.
If you cannot control this, you can store the contents
of the CallContext before you create an instance of your ServicedComponent and then load the contents back in. NOTE: You cannot take advantage of the CallContext feature in ServicedComponent applications. Microsoft does not support the use of CallContext from within ServicedComponent objects. STATUSMicrosoft
has confirmed that this is a problem in the Microsoft products that are listed
at the beginning of this article.
This problem was first corrected in Microsoft .NET
Framework Service Pack 2 (SP2).
Modification Type: | Minor | Last Reviewed: | 9/13/2005 |
---|
Keywords: | kbvs2002sp1sweep kbbug kbfix kbNetFrame100SP2fix kbRemoting KB319177 |
---|
|