IIS7 中的 DotNetOpenAuth；请求不可用
最近，我工作的公司已开始在其中之一实施 OAuth 他们的网络服务。然而，昨天我遇到了一个相当不寻常的事情 问题。
在远程计算机上调试应用程序时，我收到 以下错误：“System.Web.HttpException：请求不可用 在这种情况下”。现在，当我第一次遇到这个问题时，我发现 发现这通常与我无法使用 Global.cs的Application_Start方法中的HttpContext对象，所以我 从方法中删除了对该对象的所有引用（如所述 这里; http://mvolo.com/blogs/serverside/archive/2007/11/10/Integrated-mode-Request-is-not-available-in-this-context-in-Application_5F00_Start.aspx< /a>)
但是，在远程运行代码时问题仍然存在 计算机（安装 IIS7 配置管理器的位置）。 更重要的是，堆栈跟踪引用了名为“C:\rws\lib \dnoatst.net4\Samples\ZuydOAuthServiceProvider\Code\Global.cs”，其中 对我来说没有意义，因为实际文件位于 D:\ 磁盘。我在源代码中的任何位置都找不到对该路径的引用 代码。
有人对这个特定问题有任何经验吗？任何帮助 将不胜感激！
Recently the company I work for has begun implementing OAuth in one of
their web services. However, yesterday I came across a rather unusual
problem.
When debugging the application on a remote computer, I receive the
following error: "System.Web.HttpException: Request is not available
in this context". Now, when I first encountered this problem I found
out that this usually has to do with the fact that I can't use the
HttpContext object in the Application_Start method of Global.cs, so I
removed all references to that object from the method (as described
here;
http://mvolo.com/blogs/serverside/archive/2007/11/10/Integrated-mode-Request-is-not-available-in-this-context-in-Application_5F00_Start.aspx)
However, the problem persists when running the code on the remote
computer (which is where IIS7 configuration Manager is installed).
What's more, the stack trace refers to a path named "C:\rws\lib
\dnoatst.net4\Samples\ZuydOAuthServiceProvider\Code\Global.cs", which
makes no sense to me because the actual files are located on the D:\
disk. I cannot find a reference to that path anywhere in the source
code.
Does anyone have any experience with this particular issue? Any help
would be greatly appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
经过一番测试，这个问题似乎有一个解决方案，尽管不是完美的。将应用程序池的托管管道模式设置为“经典”似乎可以解决问题，但是，我有点担心这会在后期出现问题。
如果有人知道如何在不使用经典托管管道模式的情况下解决我最初的帖子中描述的问题，我将不胜感激您分享您的想法。
After some testing, it seems that there is a solution to this issue, albeit not a perfect one. Setting the Application Pool's managed pipeline mode to "Classic" seems to do the trick, however, I am somewhat worried that this will cause problems at a later stage.
If anyone knows how to solve the problem described in my initial post without using Classic managed pipeline mode, I would appreciate you sharing your thoughts.