In our ItemAdded event receiver code, we would like to call

Server.Execute(new MyPage(), writer, false)

to statically generate the HTML code for MyPage and store it in the RootFolder so client can access it via URL.

However, HttpContext.Current is null at the start of the ItemAdded method. I found a reference that suggested to do use the following code to create a valid HttpContext:

            StringBuilder sb = new StringBuilder();
            using (StringWriter writer = new StringWriter(sb))
                var request = new HttpRequest("", web.Url, "");
                HttpContext.Current = new HttpContext(request, new HttpResponse(writer));
                HttpContext.Current.Server.Execute(new MyPage(), writer, false);

            string formContent = sb.ToString();

However, when executing this code, I get an HttpException with an NullReferenceException InnerException in System.Web.UI.Page.SetIntrinsics().

Is this the correct way to execute a server page and return the generated contents as a string? If so, what am I missing to get the above code working? If not, what's the correct way to accomplish this task?

Update Our server needs to be configured with Basic Auth (since iOS browsers will not respond to a 401 challenge by Windows Auth when asked to download a cache.manifest file). This in turn would require us to use explicit name/password in our WebClient.DownloadString() call, something we don't have access to in our event handler code.

  • This sounds bad for a dozen different reasons. Can you explain why you are generating static copies of content in what is meant to be a dynamic system? SharePoint has Publishing features that are designed to handle most of the cases I can think of that would require such an approach. Just curious because it sounds like the above approach would actually create far, far more problems than it solves.
    – Dave Wise
    Sep 4, 2012 at 17:04
  • Our form design tool uploads a form description template to a SharePoint list. Based on that template we currently generate the appropriate HTML page on each request (by interpreting the template in the code-behind). Since the generated HTML is always the same for a given form version, we want to generate the HTML code once (at publishing time) and store it in the RootFolder rather than regenerate it each time. The above approach would leverage the existing code-behind infrastructure to generate the HTML. Sep 4, 2012 at 17:14

2 Answers 2


I think what you might be looking for is something more along these lines.

new System.Net.WebClient().DownloadString(url)

That said, this really sounds like it could be accomplished via single webpartpage and a slightly modified ContentQueryWebPart, assuming the form template details are exposed as fields in the list. Using the CQWP could eliminate the need for the code entirely.

  • The problem with this approach is that our server is configured for Basic Auth (because iOS browsers will not download the cache.manifest file using Windows Auth). This in turn requires explicit name/password credentials to authenticate the request, something we don't have access to in the event receiver. Sorry, should have mentioned that in my original post (which I will add). I'll upvote since it is a valid approach for those that use windows Auth. Sep 4, 2012 at 17:34
  • Is there a way to get name/password for use in Basic Auth for the SP admin (which is executing the event receiver)? That would solve our problem, but so far I haven't been able to find a way to do that w/o explicitly storing the password somewhere on the system (web.config, registry, etc.). The CredentialCache is of no help here. Sep 4, 2012 at 17:39
  • fetching web page content through FormsAuth is not something I've had to do but this post looks promising : stackoverflow.com/questions/450380/…. You will still need to pass a user id and password though, which likely means creating a special ID for this request in your authentication provider.
    – Dave Wise
    Sep 4, 2012 at 17:45

Based on this thread to date I recommend against the proposed approach altogether (echoing Dave). Two reasons come to mind, though there are likely more.

First, the proposed approach is ultimately just a performance optimization. Are you sure the naive approach won't scale? If not, it seems wiser to leverage e.g. caching first. Introducing unnecessary complexity is probably the most expensive and most common mistake I see on (far too many) client projects.

Second, the event receiver will only fire on one server. If you go this route, you will need a timer job or a farm-aware event receiver to write the file to all of the front end servers in the farm. Otherwise, this approach won't work when there is more than one front end server.

Regardless of the path you choose, good luck!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.