+1-888-365-2779
Try Now
More in this section

Forums / Bugs & Issues / API dependencies on HttpContext

API dependencies on HttpContext

2 posts, 0 answered
  1. Gary
    Gary avatar
    91 posts
    Registered:
    19 Jul 2007
    28 Mar 2011
    Link to this post
    I need to execute a process via a batch job that will on a nightly basis create content from external sources.

    To do this, I created a console app to make the applicable Sitefinity API calls. For the app.config file, I used similar content from the web.config file of the main site.

    However, this approach is failing because it seems that the API expects to be running within an HttpContext.

    I tracked down a couple of the root causes. In one case it is any cmsEngine provider with the attribute urlRewriteFormat set:

    if (!string.IsNullOrEmpty(this.urlRewriteFormat))
    {
        CmsHttpRequest request = new CmsHttpRequest(this.urlRewriteFormat);
        this.contentExtension = request.LongExtension;
    }

    In another case, it was specific to the Initialize method of the wiki XmlProvider:

    this.dataFile = HttpContext.Current.Request.MapPath(config["dataFile"]);


    I wonder if it is possible to mock up an HttpContext, or find another approach to overcome this limitation with the API?

    Thanks,
    Gary

  2. Gary
    Gary avatar
    91 posts
    Registered:
    19 Jul 2007
    28 Mar 2011
    Link to this post
    To answer my question (in case it's helpful to anyone else in the future):

    An HttpContext can be created using this technique.

    The website web.config file can be used for the console app config file without changes. Be sure to initialize the HttpSimulator class with the physicalApplicationPath of your website root folder. Yes, this means that the console app will only run on the same server that Sitefinity is configured on, but this shouldn't be a major issue in most scenarios.

    I also suggest that you comment out or remove the following line from within <healthMonitoring><rules>:

    <add name="SitefinityErrorHandler" eventName="All Errors" ... />

    As far as I can tell, this serves no valid purpose, and it causes a new exception to be thrown from within Sitefinity's own exception handling logic. If you don't remove this line, then the true exception is masked, which makes it very difficult to debug.
2 posts, 0 answered