Faking HttpContext to user System.Web.HttpContext.Current.Server.Execute

Question

0.00/5 (No votes)

See more:

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

Posted 29-Oct-12 12:07pm

Adam R Harris

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

dojohansen · Answer 1 · 2012-11-01T04:25:00

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".