我目前有一个WCF服务，用于执行一些数据库查询和发送邮件。简而言之，这两种方法在实现的某个地方都是异步使用HttpContext.Current。
我的最初问题是，在第一个await之后，HttpContext.Current为空，因此第二个操作失败。我现在在Google上搜索了几个小时，然后测试了所有发现的内容...自定义同步上下文，web.config中的appSettings，针对.NET 4.5，启用了ASP.NET兼容性，但没有任何效果。
然后，我发现this SO post在谈论CallContext。基本上，这个想法是将HttpContext.Current存储在CallContext中。我进行了测试，并把它工作了。但是，由于我不知道确切的CallContext是什么，所以我读了一下。
我不确定我是否真的正确理解了所有内容，但阅读后我会担心。我可能是错的，但似乎无法保证异步调用完成后恢复的线程与初始线程相同。问题是我在HttpContext中存储了多个值，而且恐怕第一种方法使用用户A值执行，然后，一旦异步调用完成，第二种方法将使用用户B值执行（因为HttpContext会不同）。
我想人们会很想告诉我只将这些值存储在CallContext中，但是在遇到WCF问题之前我创建了一个完整的体系结构，所以我不想对其进行全面的审查，这就是CallContext之所以方便的原因，因为更改很小。
有人可以告诉我我的理论是否正确？
答案 0 :(得分：1)
您应该更改服务，以使其不依赖于HttpContext.Current。最好完全不依赖HttpContext。
HttpContext.Current是等效于UI线程的服务器端。只是不要在不需要依赖它的代码上使用它。