伪造HttpContext到用户System.Web.HttpContext.Current.Server.Execute [英] Faking HttpContext to user System.Web.HttpContext.Current.Server.Execute

问题描述

大家好，

我有一种情况，我想使用一些ASP.NET服务器控件将它们添加到System.Web.Page并使用System.Web.HttpContext.Current.Execute从C#Windows库执行该页面.

我遇到的问题是System.Web.HttpContext.Current为null，因为代码在.NET库中并且正在Web请求的上下文外部执行.

所以...有什么办法可以使它起作用或伪造出来，以便呈现控件并返回HTML?我不想只在控件本身上调用RenderControl，因为这将阻止我使用事件和Ajax.

任何输入将不胜感激.

谢谢，
Adam

Hey All,

I have a situation where i would like to use some ASP.NET Server Controls add them to a System.Web.Page and execute that page using System.Web.HttpContext.Current.Execute all from a C# Windows Library.

The issue i am coming across is that System.Web.HttpContext.Current is null because the code is inside a .NET library and is being executed outside the context of a web request.

SO ... is there any way i can get this to work or fake it out so it will render my controls and return me the HTML? I don''t want to just call RenderControl on the controls themselves because that will prevent me from being able to use events and ajax.

Any input would be greatly appreciated.

Thanks,
Adam

推荐答案

据我所知，没有官方支持"的方法.通常，您应该使用WebRequest并以这种方式获取响应.

但是，如果您真的认为这是个好主意，则可以使用.net反射器，看看是否可以通过私有反射来伪造它.我曾经做过一些类似的事情.那是一个项目，其中大量业务逻辑直接依赖于内部会话"，该会话当然来自HttpContext.我们需要启动多个线程并在后台做一些事情，然后弄清楚是否可以破解HttpContext.Current使会话可以在所有线程中使用，这可以节省很多工作. (而且，我自由地承认，潜在地会打开一大罐蠕虫.但是实际上，在这种情况下，这实际上是很大的成功.)

HttpContext.Current没有设置器.但是，getter显示该属性由线程本地存储支持.因此，如果我们只能将引用从一个线程复制到另一个线程，那么我们将继续前进.

因此，我们制作了一种用于创建新线程的实用程序方法.像Thread构造函数一样，该方法采用ThreadStart委托.但是它实际上创建了它自己的类的实例，获得了对当前HttpContext的引用(该引用必须存在于开始新线程的线程中)，然后保存它，并同样保存用户提供的threadstart委托.因此，此实例方法在新线程中运行，并且可以访问线程本地存储以有效地设置"该线程中的HttpContext.Current.然后，它将调用用户提供的委托.

尽管我通常不建议这种肮脏的解决方法，但我还是由衷地建议使用类似的技术来做稍微不同的事情.随着时间的流逝，我们发现在所有后台线程中安装默认异常处理程序非常有用-通过将用户提供的委托的调用简单地包装在try块中并将该处理程序放入catch块中.其他可能的用途是在错误时和完成时提供回调(可以在启动线程时由用户提供).

As far as I know there is no way to do this that is "officially supported". Ordinarily you should use WebRequest and obtain a response that way.

However, if you really think this is a good idea you could have a look with .net reflector and see if you could fake it by private reflection. I''ve done something slightly similar once. That was a project where a ton of business logic relied directly on the "intrinsic session" which of course comes from the HttpContext. We needed to start multiple threads and do stuff in the background and figured if we could hack HttpContext.Current so session became available in all threads, that''d save us a lot of work. (And, I freely admit, potentially open up a huge can of worms. But actually it pretty much was a big success in this case.)

HttpContext.Current doesn''t have a setter. But the getter showed the property was backed by thread local store. So if only we could copy the reference from one thread to another, we''d be on our way.

So we made a utility method for creating new threads. Like the Thread constructor the method takes a ThreadStart delegate. But it actually creates an instance of it''s own class, obtains a reference to the current HttpContext (which must exist in the thread starting a new one), saves it, and likewise saves the user-provided threadstart delegate. This instance method thus runs in the new thread and can access the thread local store to effectively "set" HttpContext.Current in that thread. Then it invokes the user-provided delegate.

Although I generally wouldn''t recommend this kind of dirty workaround, I do heartily recommend using a similar technique to do slightly different things. With time, we found that it was very useful to install a default exception handler in all background threads - by simply wrapping the invocation of the user-provided delegate in a try-block and putting the handler in the catch block. Other possible uses is to provide callbacks (that can be user-provided when starting the thread) "on error" and "on completion".

这篇关于伪造HttpContext到用户System.Web.HttpContext.Current.Server.Execute的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！