В понедельник 23-го августа Microsoft «закрыла» проект ATLAS, а точнее выпустила новую версию и назвала его в AJAX 1.0 beta. Для перехода с ATLAS на эту новую версию была выложена также статья «Migrating your web page to the ASP.NET AJAX 1.0 Beta» по адресу http://ajax.asp.net/ajaxtoolkit/Walkthrough/AtlasToAspNetAjax.aspx , в которой рассказывается что необходимо сделать чтобы использовать новую версию. Честно скажу, я сразу скептически отнесся к этой статье – моё шестое чувство говорило мне, что «малой кровью» перевод проекта не обойдется и что те 4 шага, написанные в статье, будут только малой частью тех шагов, которые прийдется пройти. Данное чувство меня не обмануло. Итого сие мероприятие заняло у меня несколько часов. Постараюсь описать, что же мне пришлось проделать по пути к заветной цели. Итак, начали:
Прежде всего, если Вы создавали проект типа ATLAS, то можете заглянуть в web.config своего проекта. Ваш web.config будет иметь строки для handlers, modules и т.д., в которых явно указывается ATLAS. Теперь попробуйте создать проект типа AJAX и посмотрите его web.config J Не знаю, что конкретно нужно менять, а что нет и во что оно выльется и какие глюки будут подстерегать, но я к концу «миграции» почти полностью заменил все, что касалось ATLAS.
Следующий момент – удаляем все dll, что касаются ATLAS из bin.
Далее – добавляем ссылку на \Program Files\Microsoft ASP.NET\ASP.NET 2.0 AJAX Extensions\[version]\microsoft.web.extensions.dll. Данная dll находится в GAC, поэтому не будет скопирована в bin
Добавляем ссылку на AjaxControlToolkit (данная библиотека качается по ссылке http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=AtlasControlToolkit ) – это то, что заменяет нам AtlasControlToolkit (понятное дело, что если в проекте AtlasControlToolkit не использовался – ничего добавлять не нужно).
Далее, как сказано в статье «Migrating your web page to the ASP.NET AJAX 1.0 Beta» , меняем <%@ Register Assembly="AtlasControlToolkit" Namespace="AtlasControlToolkit" TagPrefix="atlasToolkit" %>
на
<%@ Register Assembly="AjaxControlToolkit" Namespace="AjaxControlToolkit" TagPrefix="ajaxToolkit" %>
Далее меняем все элементы с тегом <atlas: на тег <asp:
Меняем для всех UpdatePanel атрибут Mode на UpdateMode
UpdatePanel в новой версии не поддерживает старые триггеры типа ControlEventTrigger и ControlValueTrigger – теперь есть AsyncPostBackTrigger и PostBackTrigger. Соответственно мы должны везде заменить триггеры (и в коде в том числе).
Некоторые разработчики (и я в том числе) имели привычку размещать ScriptManager в head страницы (чтобы не маячило в form). Теперь scriptManager, размещенный в заголовке страницы, дает ошибку.
Exception Details: System.Web.HttpException: Control 'scriptManager' of type 'ScriptManager' must be placed inside a form tag with runat=server.
Т.е. на всех страницах переносим ScriptManager в тег form.
И наверное будет еще ряд проблем с данными контролами и их свойствами в code-behind. Например, мне пришлось заменить
PopupControlExtender.GetCurrent(this.Page).Commit(Calendar1.SelectedDate.ToShortDateString());
На
PopupControlExtender.GetProxyForCurrentPopup(this.Page).Commit(Calendar1.SelectedDate.ToShortDateString());
После этих проделанных шагов проект наконец-то скомпилировался J
И напоследок отказывается работать следующий код – я, для того, чтобы обновлять UpdatePanel из клиентских скриптов, добавляю невидимую кнопку и цепляю ее как триггер на данную UpdatePanel. После чего вызываю клиенский код, который генерируется следующим серверным кодом:
Page.ClientScript.GetPostBackEventReference(btnUpdate, "");
Т.е. получается из клиентского скрипта имитируется нажатие на кнопку и соответственно обновляется UpdatePanel. Так вот, у меня этот код перестал работать, а точнее стал перегружать всю страницу. Лично я не нашел ничего лучшего как разместить эту кнопку в нулевой iframe, предварительно установив для нее Visible=”true” (видимая кнопка работает правильно).