2009-06-29 26 views
1

J'ai une page ASPX personnalisée que j'ai déployée dans le dossier ISV. La page contient un contrôle ScriptManager.Dynamics CRM 4.0, utilisation d'AJAX sur des pages ASPX personnalisées

Pour que la page se charge, j'ai besoin d'inclure les paramètres de configuration AJAX quelque part. Pour un site web personnalisé, je peux mettre la configuration dans le fichier web.config. Mais avec Dynamics CRM, les changements de web.config ne sont pas supportés ... et, autant que possible, je voudrais rester du côté "supporté".

J'ai essayé d'utiliser la fonctionnalité "fichiers de configuration multiples" d'ASP.NET et de placer un fichier web.config dans le dossier ISV. Mais l'application CRM semble ignorer mon fichier de configuration.

S'il vous plaît me conseiller sur la façon d'inclure AJAX sur ma page ASPX personnalisée.

Merci

Répondre

1

Se référant à MSCRM 4.0 Extension MOC, vous pouvez inclure votre propre web.config dans votre application Web ASP.NET personnalisé dans le dossier ISV. Notez simplement que vous pouvez supprimer les modules HttpModules MapOrg et CrmAuthentication qui sont utilisés par le fichier web.config racine MS-CRM.

Ce sont l'extrait de code exemple de supprimer les deux HttpModules

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

Vous pouvez également consulter Ronald Lemmen post et Cesar post

Hope this helps,

hadi Teo

1

Si vous retirez les modules CrmAuthentication et MapOrg de votre ISV \ yoursolution \ web.config, vous ne pourrez plus réutiliser l'utilisation finale L'identité de r lors de l'appel de services Web.

Cette solution vous permettra d'utiliser UpdatePanel et ScriptManager dans CRM 4.0 sans modifier le web.config de CRM et sans que votre dossier de solution ISV soit sa propre application IIS. Pour ce faire, nous devrons corriger la sortie du contrôle ScriptManager avec un filtre de réponse afin que le navigateur Web tente de demander le fichier ScriptResource.axd dans notre dossier de solution ISV. Ensuite, afin de convaincre le gestionnaire de ressources de script de traiter la requête, il doit sembler qu'il est demandé dans le répertoire racine pour deux raisons idiotes. Donc, nous aurons besoin de créer et de câbler notre propre Script Resource Handler qui va simplement réparer et transmettre la requête au gestionnaire normal.

Pour intercepter et FIXUP les balises de script, dans votre événement Load page ASPX:

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

Puis câbler le gestionnaire pour intercepter la demande, modifier votre ISV \ yoursolution \ fichier web.config. Dans la configuration \ system.web \ section httpHandlers, commentez l'élément add qui spécifie path = « ScriptManager » et insérer un nouvel élément d'ajout comme indiqué:

<!--<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"/> 

Assurez-vous que vous définissez l'attribut de type afin qu'il fait référence à l'espace de nom de la classe dans votre projet et à votre nom d'assembly.

comprennent ensuite ces deux classes dans votre 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)); 
    } 
} 

Bonne chance!

Questions connexes