CODEWITHSUNDEEP
asp.net-ajaxweb-configdynamics-crm
Ciprian Bortos
Ciprian Bortos

Reputation: 224

Dynamics CRM 4.0, using AJAX on custom ASPX pages

I have a custom ASPX page, that I deployed in the ISV folder. The page contains a ScriptManager control.

In order for the page to load, I need to include the AJAX configuration settings somewhere. For a custom website, I can put the configuration inside web.config file. But with Dynamics CRM, the changes to web.config are not supported ... and, as much as possible, I would like to stay on the "supported" side.

I tried to use the "multiple configuration files" feature of the ASP.NET and place a web.config file inside the ISV folder. But the CRM application seems to ignore my config file.

Please advise me on how to include AJAX on my custom ASPX page.

Thank you

Upvotes: 1

Views: 2787

Answers (2)

Dan
Dan

Reputation: 11

If you remove the CrmAuthentication and MapOrg modules from your ISV\yoursolution\web.config then you won't be able to re-use the end user's identity when calling web services.

This solution will allow you to use the UpdatePanel and ScriptManager in CRM 4.0 without modifying CRM's web.config and without making your ISV solution folder it's own IIS app.

To do this we will need to fixup the ScriptManager control's output with a Response Filter so that the web browser attempts to request the ScriptResource.axd file within our ISV solution folder. Then in order to convince the Script Resource Handler to process the request, it has to look like it's being requested at the root directory for two silly reasons. So, we'll need to create and wire up our own Script Resource Handler that will simply fixup and proxy the request to the normal handler.

To intercept and fixup the script tags, in your aspx page's Load event:

protected void Page_Load(object sender, EventArgs e)
{
    Response.Filter = new ScriptResourceFixupFilter(Response.Filter);
}

Then to wire up the handler to intercept the request, modify your ISV\yoursolution\web.config file. In the configuration\system.web\httpHandlers section, comment out the add element that specifies path="ScriptManager" and insert a new add element as shown:

  <!--<add verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" validate="false"/>-->

  <add verb="GET,HEAD" path="ScriptResource.axd" type="YourNamespace.ScriptResourceHandlerProxy, YourAssemblyNameWithoutDllExtension"/>

Make sure that you set the type attribute so that it references the class's namespace within your project and your assembly name.

Then include these two classes in your solution:

/// <summary>
/// This is used to resolve compatibility issues with CRM's web.config, it doesn't have entries required for
/// the built in System.Web.Handlers.ScriptResourceHandler used Microsoft's ASP.Net Ajax components (i.e. ScriptManager, UpdatePanel, etc...)
/// 
/// This class will pick up the request for the script resource,
///  translates the request url so it appears to come at the to the app root path
/// </summary>
public class ScriptResourceHandlerProxy : System.Web.Handlers.ScriptResourceHandler
{
    protected override void ProcessRequest(HttpContext context)
    {
        // in order to trick the ScriptResourceHandler into handling this request, 
        //  we need to show it that the path of the request context is at the root of the web application
        var uri = new UriBuilder(context.Request.Url.AbsoluteUri)
        {
            Path = VirtualPathUtility.ToAbsolute("~/ScriptResource.axd"),
            Query = null
        };

        var compatableContext = new HttpContext(
            new HttpRequest("ScriptResource.axd", uri.Uri.ToString(), (context.Request.Url.Query ?? String.Empty).TrimStart('?')),
            context.Response);

        base.ProcessRequest(compatableContext);
    }
}

/// <summary>
/// This is used to resolve compatibility issues with CRM's web.config, it doesn't have entries required for
/// the built in System.Web.Handlers.ScriptResourceHandler used Microsoft's ASP.Net Ajax components (i.e. ScriptManager, UpdatePanel, etc...)
/// 
/// Replace references to src="/ScriptResource.axd" with "/ISV/YourSolution/ScriptResource.axd" so that the 
/// ASP.Net runtime picks up on our web.config entries that include the asp.net Ajax entries and passes the 
/// request along to our script resource handler proxy class
/// </summary>
public class ScriptResourceFixupFilter : MemoryStream
{
    private Stream _output;
    public ScriptResourceFixupFilter(Stream output)
    {
        this._output = output;
    }

    public override void Write(byte[] buffer, int offset, int count)
    {
        var content = UTF8Encoding.UTF8.GetString(buffer);
        content = content.Replace(@"""/ScriptResource.axd", @"""/ISV/YourSolution/ScriptResource.axd");
        _output.Write(UTF8Encoding.UTF8.GetBytes(content), offset, UTF8Encoding.UTF8.GetByteCount(content));
    }
}

Best of luck!

Upvotes: 1

hadi teo
hadi teo

Reputation: 936

Referring to MSCRM 4.0 Extension MOC, you can include your own web.config in your custom ASP.NET web application inside the ISV folder.

Just take note that, you can remove MapOrg and CrmAuthentication HttpModules which are used by the root MS-CRM web.config.

These are the sample code snippet of removing the two HttpModules 

<configuration>
  <system.web>
     <httpModules>
        <clear/>
     </httpModules>
  </system.web>
</configuration>

You can also refer to Ronald Lemmen post and Cesar post

Hope this helps,

hadi teo

Upvotes: 1

Related Questions