In 91

原文網址：Sys.WebForms.PageRequestManagerParserErrorException - what it is and how to avoid it

使用UpdatePanel的時候，很容易遇上的問題。
尤其是ASP或ASP.NET 1.1 升級到2.0，使用UpdatePanel可能會因為舊的寫法導致這樣的exception出現。

以下整理一下原文摘要：

常見原因：

1. 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.
2. Response filters:
   Similar to Response.Write(), response filters can change the rendering in such a way that the UpdatePanel won't know.
3. HttpModules:
   Again, the same deal as Response.Write() and response filters.
4. 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.
5. 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.

建議解法：

1. Calls to Response.Write():
   Place an <asp:Label> or similar control on your page and set its Text property. The added benefit is that your pages will be valid HTML. When using Response.Write() you typically end up with pages that contain invalid markup.
2. 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.
3. HttpModules:
   Same as response filters.
4. 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.
5. 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.

在UpdatePanel裡非同步Postback可能帶來的問題與解法：
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:

1. The easiest is to simply place the button outside of any UpdatePanels. Unfortunately the layout of your page might not allow for this.
2. 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.
3. 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.

簡單說，會造成這個exception的主因就是Response.Write()和Server.Transfer()的用法，
Response.Write除了可能會造成這樣的exception外，也會造成CSS亂掉，所以基本上在ASP.NET應該是可以盡量避免使用這樣的輸出文字方式了。
而Server.Transfer()會無法parsed HTML而造成同樣的錯誤。

先瞭解UpdatePanel的原理，目的，以及執行流程，
不難想像為啥一些相關的function，或以前可以執行的程式，當使用了UdpatePanel為什麼會帶來這麼多問題。
最近碰到的問題是jQuery的document.ready + UpdatePanel + PostBack，造成document.ready中對DOM的動作在postback後失效。
原因就是Partial Render造成的。

想比較深入的瞭解AJAX.NET的UpdatePanel運作原理，請參考之前這篇文章：[AJAX]AJAX與UpdatePanel簡介

---

blog 與課程更新內容，請前往新站位置：http://tdd.best/