Sys.WebForms.PageRequestManagerParserErrorException - what it is and how to avoid it
6676 단어 exception
If you've used the Microsoft ASP.NET AJAX UpdatePanel control, there's a good chance you've hit the "Sys.WebForms.PageRequestManagerParserErrorException" error.
What's a PageRequestManagerParserErrorException?
The UpdatePanel control uses asynchronous postbacks to control which parts of the page get rendered. It does this using a whole bunch of JavaScript on the client and a whole bunch of C# on the server. Asynchronous postbacks are exactly the same as regular postbacks except for one important thing: the rendering. Asynchronous postbacks go through the same life cycles events as regular pages (this is a question I get asked often). Only at the render phase do things get different. We capture the rendering of only the UpdatePanels that we care about and send it down to the client using a special format. In addition, we send out some other pieces of information, such as the page title, hidden form values, the form action URL, and lists of scripts.
As I mentioned, this is rendered out using a special format that the JavaScript on the client can understand. If you mess with the format by rendering things outside of the render phase of the page, the format will be messed up. Perhaps the most common way to do this is to call Response.Write() during Page's Load event, which is something that page developers often do for debugging purposes.
The client ends up receiving a blob of data that it can't parse, so it gives up and shows you a PageRequestManagerParserErrorException. Here's an example of what the message contains:
---------------------------
Microsoft Internet Explorer
---------------------------
Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.
Details: Error parsing near 'Hello, World!106|upd'. --------------------------- OK ---------------------------
If you ask me, this error message is not all that bad. After all, I'm the one that made it :) The details indicate what was being parsed when it decided to give up. You can see the part of the text from my Response.Write(), and immediately after that is part of the special format I keep mentioning.
Why do I keeping getting a PageRequestManagerParserErrorException?
Well, chances are you're doing one of the things mentioned in the error message. Here are the most common reasons and why they don't work:
Calls to Response.Write():
By calling Response.Write() directly you are bypassing the normal rendering mechanism of ASP.NET controls. The bits you write are going straight out to the client without further processing (well, mostly...). This means that UpdatePanel can't encode the data in its special format.
Response filters:
Similar to Response.Write(), response filters can change the rendering in such a way that the UpdatePanel won't know.
HttpModules:
Again, the same deal as Response.Write() and response filters.
Server trace is enabled:
If I were going to implement trace again, I'd do it differently. Trace is effectively written out using Response.Write(), and as such messes up the special format that we use for UpdatePanel.
Calls to Server.Transfer():
Unfortunately, there's no way to detect that Server.Transfer() was called. This means that UpdatePanel can't do anything intelligent when someone calls Server.Transfer(). The response sent back to the client is the HTML markup from the page to which you transferred. Since its HTML and not the special format, it can't be parsed, and you get the error.
How do I avoid getting a PageRequestManagerParserErrorException?
To start with, don't do anything from the preceding list! Here's a matching list of how to avoid a given error (when possible):
Calls to Response.Write():
Place an
Response filters:
The fix might just be to not use the filter. They're not used very often anyway. If possible, filter things at the control level and not at the response level.
HttpModules:
Same as response filters.
Server trace is enabled:
Use some other form of tracing, such as writing to a log file, the Windows event log, or a custom mechanism.
Calls to Server.Transfer():
I'm not really sure why people use Server.Transfer() at all. Perhaps it's a legacy thing from Classic ASP. I'd suggest using Response.Redirect() with query string parameters or cross-page posting.
Another way to avoid the parse error is to do a regular postback instead of an asynchronous postback. For example, if you have a button that absolutely must do a Server.Transfer(), make it do regular postbacks. There are a number of ways of doing this:
The easiest is to simply place the button outside of any UpdatePanels. Unfortunately the layout of your page might not allow for this.
Add a PostBackTrigger to your UpdatePanel that points at the button. This works great if the button is declared statically through markup on the page.
Call ScriptManager.RegisterPostBackControl() and pass in the button in question. This is the best solution for controls that are added dynamically, such as those inside a repeating template.
Summary
I hope I've answered a lot of questions here and not angered too many of you. We're looking at ways to improve some of these situations in the next version of ASP.NET, but of course there are no guarantees. If you avoid changing the response stream, you're good to go. If you absolutely must change the response stream, simply don't do asynchronous postbacks.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
Exception Class에서 에러 코드 해석 ~초기초편~직장에서 C# 프로젝트가 내뿜는 오류 코드를 구문 분석하고 오류의 위치를 확인하기 위해 Exception class를 활용할 수 있었습니다. 지금까지 Exception Class 에 대해서 별로 파악할 수 없었기 때...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.