Если вы удалите модули CrmAuthentication и MapOrg из своего ISV \ yoursolution \ web.config, то вы не сможете повторно использовать идентификатор конечного пользователя при вызове веб-служб.
Это решение позволит вам использовать UpdatePanel и ScriptManager в CRM 4.0 без изменения файла web.config CRM и без создания папки решения ISV в качестве собственного приложения IIS.
Для этого нам нужно исправить вывод элемента управления ScriptManager фильтром отклика, чтобы веб-браузер пытался запросить файл ScriptResource.axd в нашей папке решения ISV. Затем, чтобы убедить обработчик ресурсов сценариев обработать запрос, он должен выглядеть так, будто его запрашивают в корневом каталоге по двум глупым причинам.
Итак, нам нужно создать и подключить наш собственный обработчик ресурсов сценариев, который просто исправит и передаст запрос обычному обработчику.
Чтобы перехватить и исправить теги скрипта, в событии Load вашей страницы aspx:
protected void Page_Load(object sender, EventArgs e)
{
Response.Filter = new ScriptResourceFixupFilter(Response.Filter);
}
Затем, чтобы подключить обработчик для перехвата запроса, измените файл ISV \ yoursolution \ web.config. В разделе configuration \ system.web \ httpHandlers закомментируйте элемент add, который указывает path = "ScriptManager", и вставьте новый элемент add, как показано ниже:
<!--<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"/>
Убедитесь, что вы установили атрибут type так, чтобы он ссылался на пространство имен класса в вашем проекте и имя вашей сборки.
Затем включите эти два класса в ваше решение:
/// <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));
}
}
Удачи!