只在UnitTest和WebHost中的出现的关于LogicalCallContext的严重问题

最近一直在进行公司内部框架的升级工作,其中一个小的部分就是通过HttpSessionState和CallContext建立一套统一的、可扩展的用于管理上下文信息的框架。在为写好的程序编写Unit Test和QuickStart的时候,遇到了两个基于LogicalCallContext的严重问题。导致这两个问题的根源还没有来得及去追踪,或许是微软VS  Unit Test框架本身和WebHost本身的一个Bug。现在将其写出来,一来是希望读者在遇到相同情况的时候知道LogicalCallContext可能是影响因素之一,另一方面也希望借助社区的力量快速找到问题的症结。以下内容假定读者已经对CallContext有一个大概的了解,并且明白LogicalCallContext和IllogicalCallContext之间的区别。对此不了解的读者,可以参考我的文章《如何实现对上下文(Context)数据的统一管理 》。

一、在VS Unit Test下设置LogicalCallContext导致的序列化问题

为了演示在Unit Test下设置LogicalCallContext会导致怎样的问题,为此我写了一个非常简单的例子去重现它。首先我定义了如下一个形如Key-Value 的类型:LogicalContextItem<TValue>:

   1: [Serializable]
   2: public class LogicalContextItem<TValue>
   3: {
   4:     public string Key { get; private set; }
   5:     public TValue Value { get; set; }
   6:  
   7:     public LogicalContextItem(string key, TValue value)
   8:     {
   9:         if (string.IsNullOrEmpty(key))
  10:         {
  11:             throw new ArgumentNullException("key");
  12:         }
  13:         this.Key = key;
  14:         this.Value = value;
  15:     }
  16: }

然后通过如下一个TestMethod测试一个以LogicalCallContext的形式保存的上下文(通过调用CallContext的静态方法LogicalSetData)是否可以通过相同的Key被正常获取。

   1: [TestClass]
   2: public class LogicalSetDataFixture
   3: {
   4:     [TestMethod]
   5:     public void LogicaSetData()
   6:     {
   7:         LogicalContextItem<string> userName = new LogicalContextItem<string>("__userName", "Foo");
   8:         CallContext.LogicalSetData(userName.Key, userName);
   9:         Assert.AreEqual<string>("Foo", ((LogicalContextItem<string>)CallContext.LogicalGetData("__userName")).Value);
  10:     }
  11: }

但是运行上面的UnitTest的时候,在TestResult对话框中会出现一个Error。从下图中我们可以看出这是一个序列化的错误,具体的出错信息为:Unit Test Adapter threw exception: Type is not resolved for member 'UnitTests.LogicalContextItem`1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]],UnitTests, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null',即我们自定义的类型无法解析。这就有点让人费解了,在这个实例中,LogicalContextItem<TValue>:类型本身是直接定义在UnitTest这个项目之中的,何来无法解析之理。

二、在VS ASP.NET WebHost下设置LogicalCallContext导致的序列化问题

我们知道,为了给基于ASP.NET的Web应用的开发者带来便利,Visual Studio内置了一个简单(和IIS比较而言)的Web应用承载工具,即WebHost。如果采用基于WebHost的承载方式(这是默认的承载方式),上面的错误同样会发生。为了演示,我们同样使用上面定义的LogicalContextItem<TValue>类型,然后在一个单纯的WebPage中的Load事件处理方法中编写了如下一段简单的代码:

   1: public partial class _Default : System.Web.UI.Page
   2: {
   3:     protected void Page_Load(object sender, EventArgs e)
   4:     {
   5:         LogicalContextItem<string> userNameContext = new LogicalContextItem<string>("__userName", "Foo");
   6:         CallContext.LogicalSetData(userNameContext.Key, userNameContext);
   7:         var userName = ((LogicalContextItem<string>)CallContext.LogicalGetData("__userName")).Value;
   8:         Response.Write(userName);
   9:     }
  10: }

直接运行上面的程序,SerializationException异常照常被抛出,从下图给出的错误对话框可以看出,该异常具有和上面完全一样的错误信息,即不能解析我们自定义的LogicalContextItem<TValue>类型。

为了找出抛出SerializationException异常的根源,我们可以来该异常的StatckTrace。从下面给出的内容,我们可以看出来该异常最终就是通过WebHost抛出来得。

   1: at Microsoft.VisualStudio.WebHost.Host.ProcessRequest(Connection conn)
   2: at Microsoft.VisualStudio.WebHost.Server.OnSocketAccept(Object acceptedSocket)
   3: at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
   4: at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
   5: at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   6: at System.Threading.ThreadPoolWorkQueue.Dispatch()
   7: at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

三、采用IIS承载我们的Web应用可以解决上述问题

为什么我说这个问题只和内置于VS中的Web应用承载工具WebHost有关呢?一来是因为上面给出的异常StackTrace已经明显反映了异常最后总就是从WebHost跑出来的。另一个主要的原因就是,如果我直接采用IIS来承载的话,运行上述的代码后一切正常。有兴趣的读者可以从这里下载实例程序进行试验。你只需要该Web应用进行了如下配置,放弃使用Vistual Studio Development Server,而选用Local IIS Web Server即可。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏更流畅、简洁的软件开发方式

数据访问函数库 for ado.net2.0

前言 源代码和调用演示下载:http://www.cnblogs.com/jyk/archive/2008/04/25/1170979.html 数据访问函...

20470
来自专栏大内老A

Dora.Interception,为.NET Core度身打造的AOP框架:全新的版本

Dora.Interception 1.0(Github地址:可以访问GitHub地址:https://github.com/jiangjinnan/Dora)...

36350
来自专栏恰童鞋骚年

NoSQL初探之人人都爱Redis:(2)Redis API与常用数据类型简介

  首先,不得不说Redis官方提供了众多的API开发包,但是目前Redis官方版本不支持.Net直接进行连接,需要使用一些第三方的开源类库。目前最流行的就是S...

9410
来自专栏大内老A

WCF技术剖析之十七:消息(Message)详解(上篇)

消息交换是WCF进行通信的唯一手段,通过方法调用(Method Call)形式体现的服务访问需要转化成具体的消息,并通过相应的编码(Encoding)才能通过传...

48190
来自专栏王磊的博客

Thread线程的深刻理解和代理方法参数[有图有真相]

在这说的是Thread的基本用法,线程池ThreadPool在这就不说的,以前的blog有写,基本上两个用法都是相同的。基本用法和图,不需要的大鸟请绕行,谢谢!...

36780
来自专栏FreeBuf

clrinject:向CLR Runtimes和AppDomain中注入代码的工具

clrinject是一款可将C#,EXE或DLL程序集,注入另一个进程CLR Runtimes和AppDomain的工具。注入的程序集可访问injectee进程...

13730
来自专栏大内老A

[ASP.NET Web API]如何Host定义在独立程序集中的Controller

通过《ASP.NET Web API的Controller是如何被创建的?》的介绍我们知道默认ASP.NET Web API在Self Host寄宿模式下用于...

22280
来自专栏京东技术

飞哥教你使用异步编程提升服务性能

40440
来自专栏WebApiClient

WebApiClient基础

如果接口IMyWebApi有多个方法且都指向同一服务器,可以将请求的域名抽出来放到HttpHost特性。

80300
来自专栏大内老A

[WCF权限控制]从两个重要的概念谈起:Identity与Principal[下篇]

毫不夸张地说,安全主体(Principal)是整个授权机制的核心。我们可以简单地将将安全主体定义成能够被成功实施授权的主体。一个安全主体具有两个基本的要素:基于...

25080

扫码关注云+社区

领取腾讯云代金券