Ошибка ASP.NET Ajax: Sys.WebForms.PageRequestManagerParserErrorException

Есть отличная запись в блоге Эйлона Липтона. Он содержит множество советов, как избежать этой ошибки:

Sys.WebForms.PageRequestManagerParserErrorException - что это такое и как этого избежать

Прочтите и комментарии. Есть комментарий кого-то с той же проблемой: «Я решил это изменить время простоя сервера моего пула приложений на IIS. Было всего 5, поэтому я увеличил его и теперь работает».

«Элемент управления UpdatePanel использует асинхронные обратные передачи для управления тем, какие части страницы должны отображаться. Он делает это с помощью целого набора JavaScript на клиенте и целого набора C# на сервере.

Асинхронные обратные передачи точно такие же, как обычные обратные передачи, за исключением одной важной вещи: рендеринга. Асинхронные обратные передачи проходят через те же события жизненного цикла, что и обычные страницы (это вопрос, который мне часто задают).

Только на этапе рендеринга все меняется. Мы фиксируем рендеринг только тех UpdatePanels, которые нам интересны, и отправляем его клиенту в специальном формате. Кроме того, мы рассылаем некоторые другие части информации, такие как заголовок страницы, скрытые значения формы, URL-адрес действия формы и списки скриптов ».

Наиболее частые причины этой ошибки:

1. Призывы к Response.Write ():
2. Фильтры ответов
3. HttpModules
4. Трассировка сервера включена
5. Вызовы на Server.Transfer ()

Я решил ту же самую проблему, удалив Content-Type: из раздела Custom HTTP Headers на вкладке HTTP Headers в IIS. Это нарушало кодировку страницы и каким-то образом влияло на Ajax в целом.

Content-Type, который я настроил в IIS, устанавливал кодировку ISO-8859-1.

Это может быть немного взломано, но это решило проблему для меня. У меня не было ни одной из распространенных причин ошибки, поэтому я просто вставил этот лейкопластырь при загрузке страницы:

if (Session.SessionID == "")
{
    Page.Session.Add("SessionID", Session.SessionID);
}

Проблема: Sys.WebForms.PageRequestManagerParserErrorException возникнет при перенаправлении вашей страницы, скажем, нажмите кнопку внутри UpdatePanel в aspxAjax.

Решение:

1. Добавьте кнопку «GoTo» на свою страницу aspx, где используется панель обновлений, и добавьте ее за пределы панели обновлений.

2. В вашем коде назначьте ur только что зарегистрированный идентификатор пользователя переменной сеанса, скажем, Session["UseridJustregistered"]=Id из БД или UsernameField

3. Respose.Redirect("regSucces.aspx?urlid='" + Session["UseridJustregistered"] + "'");

4. Проверьте, является ли Session["UseridJustregistered"] нулевым или нет

Это СТАРЫЙ классический способ ASP, который может решить нашу проблему, и к тому времени, когда Microsoft найдет решение, мы сможем решить эту проблему.

Возможно, при ответном посте произошла ошибка. В этом случае вы можете просмотреть подробную информацию об ошибке, добавив PostBackTrigger на панель обновлений и указав кнопку, которая вызывает проблему:

    <asp:updatepanel ID = "updatepanel1" runat = "server">
        <Triggers>
            <asp:PostBackTrigger ControlID = "button1" /> 
        </Triggers>
        <ContentTemplate>

        </ContentTemplate>
    </asp:updatepanel>

Я решил эту же проблему, удалив ошибочно вложенные UpdatePanels.

Это случилось со мной, и ни одна из причин из списка в ответе не применима. Я не нашел корня проблемы, пока полностью не отключил AJAX. Обнаружено, что код сохраняет объект в ViewState, который содержит несериализуемый объект. Я сделал объект сериализуемым, и он снова начал работать.

Я наконец решил свой вариант этой же проблемы. Я пытался скопировать / переместить выбранное значение между двумя списками в веб-форме. В моем случае мне пришлось специально вызвать {listbox} .ClearSelection () перед выполнением действия во второй раз.

Очевидно, что это сообщение о проблеме / ошибке может возникнуть по множеству причин.

Смена пула приложений С ИНТЕГРИРОВАННОГО на asp.net classic решила проблему для меня.

Я тоже получил эту ошибку. Решение, о котором сообщил "user1097991", решило это на некоторое время (я использовал несериализованные объекты в viewstate)

Но позже ошибка вернулась снова, теперь уже случайным образом. После некоторого поиска я получил ответ: состояние просмотра становилось слишком большим и было усечено. Я отключил некоторые состояния просмотра в сетках и меню, и проблема больше не проявлялась.

Я обнаружил, что моя проблема связана с отображением нулевого символа в привязке данных GridView. Ожидаемая длина ответа не соответствовала фактической длине текста ответа, что привело к возникновению ошибки. Как только я исправил данные в базе данных, я больше не получал ошибки. Окончательным исправлением будет очистка текста, отображаемого во время события RowDataBound.

Просматривая базу данных, я не мог увидеть плохие данные, поскольку SQL Server 2008 не показывает текст, если в строке есть символ NUL (Char (0)). В событии RowDataBound моего GridView я добавил код, который генерирует исключение для любого текста, в котором есть специальные символы. Вот как я нашел запись, содержащую нулевые символы.

tl; dr - Проверить наличие нулевых символов в отображаемом HTML.

Также имейте в виду, что это может быть вызвано неправильной кодировкой html того, что вы можете отображать на странице с помощью частичных обратных передач.

У меня была точно такая же ошибка.

Для меня это было

<add name = "ScriptModule" type = "System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>

Отсутствует в разделе httpModules файла web.config (приложение .Net 3.5)

Эта ошибка может быть связана со многими разными вещами.

В нашем случае проблема была вызвана перезаписью прокси в пути. Перезапись изменила содержимое ответа панели обновлений. Но этот ответ также содержит исходный размер. Механизм перезаписи не может знать, что несколько байтов ответа действительно содержат исходный размер ответа, и его также следует изменить.

Ответ панели обновлений начинается так:

1|#||4|30502|updatePanel|pnlUpdate| ...

30502 - это исходный размер обновляемого контента. Механизм перезаписи изменяет вывод, но размер остается неизменным => исключение ошибки парсера.

Я не вижу способа решить эту проблему со стороны клиента. Нам нужно будет узнать, как именно было изменено содержимое, а затем каким-то образом изменить размер ответа, прежде чем UpdatePanel ClientScript начнет его обрабатывать.

Обновите ScriptMode до "Release"

<asp:ScriptManager ID = "ScriptManager" runat = "server" ScriptMode = "Release"></asp:ScriptManager>