ScriptManager

看一下<asp:ScriptManager>标签所支持的属性：

1. 1、AllowCustomError：在异步更新发生异常时是否使用Web.config中<customErrors>这一节的设定。<customErrors>中可以指定应用程序级别的错误处理页面，如果我们比较懒，则可以设定该属性为true，让发生异常后和普通ASP.NET程序一样重定向至某个专门显示错误的页面。一般来讲，最好设置其为false，因为这是Ajax程序，页面跳转是我们应该竭力避免的。
   2、AsyncPostBackErrorMessage：异步更新发生异常时发送给客户端的错误信息，可以在AsyncPostBackError事件的处理函数中根据异常的不同而动态设定该信息。然后客户端Web Form框架就可以格式化并显示给用户，这也是我推荐的Ajax异常处理方式。
   3、AsyncPostBackTimeout：异步更新的超时时限，单位为秒，默认值为90。没啥多说的，没事就别改了。
   4、EnablePartialRendering：（终于看到一个在Atlas中曾经有的属性了，好激动……）是否支持页面局部更新，默认值改为true，这样在用UpdatePanel的时候就不必每次都要留意设置ScriptManager的该属性了，不过也自然地带来了效率上的轻微影响。究竟何种方式最好，也是谓仁者见仁，智者见智的问题。
   5、ScriptMode：指定使用客户端脚本的版本（Debug或者Release），该属性的设置结果同样受制于配置文件中retail相关设置，详请参考http://ajax.asp.net/docs/mref/332fcb41-e4ab-4c1f-bb5e-61b49035af74.aspx 。需要注意的是对于自定义脚本，若该属性设置为Debug或程序实际运行时被认为需要加载Debug版本的脚本，则脚本文件名将自动添加一个“debug”部分，例如“myjs.js”将自动变为“myjs.debug.js”。（显得有些怪异，预先约定太多了，或许不是一件好事）
   6、ScriptPath：这个属性让我非常郁闷！官方的解释是“作为所有脚本文件的根目录（全局路径）”。按照我现在的理解，该属性旨在方便地替换掉现有的某个版本的脚本，而不必在每个<asp:ScriptReference>中逐一更改。当我们设定了该属性之后，比如设定为“~/dflying”，则客户端脚本的引用方式就会变成“<script src="~dflying/Microsoft.Web.Extensions/1.0.61025.0/Microsoft.Web.Resources.ScriptLibrary.MicrosoftAjax.debug.js" type="text/javascript"></script>”这样的静态脚本引用，而不是默认的通过axd资源得到，格式为“ScriptPath+程序集名+版本号+脚本文件名”。这样如果我们对框架自带的某个脚本进行了修改，则可以使用这种方法将修改后的新版本JavaScript文件引入到程序中，而且，这种静态文件的引用方法还不知不觉地提高了程序的执行效率。
   7、OnAsyncPostBackError：指定AsyncPostBackError事件的服务器端处理函数，在该处理函数中我们可以得到引发的异常，并根据不同的异常设置不同的AsyncPostBackErrorMessage，给用户足够友好的提示。
   OnResolveScriptReference：指定ResolveScriptReference事件的服务器端处理函数，在该处理函数中我们可以修改某一条脚本的相关信息，例如路径，名称，版本（Debug或者Release）等。
   
   

接下来让我们看看<asp:ScriptManager>标签中的各种子标签的变化：

1、<ErrorTemplate>标签

   整个删除。因为有了AsyncPostBackErrorMessage属性、OnAsyncPostBackError事件以及客户端Web Form框架，所以我们开发者可以极其灵活地完全定制异常的显示界面，而不用局限在原有的<ErrorTemplate>中。

   ASP.NET AJAX中默认的异步更新异常的显示界面就是一个简单的JavaScript alert()对话框。

2、<asp:ScriptReference>标签

    <asp:ScriptReference>标签包含在<Scripts>标签中，用来为页面引入一个客户端JavaScript脚本。如果程序中需要使用Microsoft ASP.NET AJAX CTP Beta中的附加脚本，或是我们自己编写的自定义脚本，则应该使用该标签引入。<asp:ScriptReference>标签中移除了ScriptName枚举的支持，目前支持如下属性

    Assembly：要引用的脚本所嵌入的程序集。
    Name：嵌入到程序集中的某个脚本的资源名称。以上两个属性通常成对使用，例如：<asp:ScriptReference Name="Microsoft.Web.Resources.ScriptLibrary.PreviewGlitz.js"  Assembly="Microsoft.Web.Preview" />，就引入了Microsoft.Web.Preview.dll中的名为Microsoft.Web.Resources.ScriptLibrary.PreviewGlitz.js的JavaScript资源。
    Path：通过路径指定将要引用的自定义脚本文件。
    ScriptMode：作用同<asp:ScriptManager>标签中同名属性的定义，并将覆盖其中的设定。同样需要注意的是，若该属性设置为Debug或程序实际运行时被认为需要加载Debug版本的脚本，则脚本文件名将自动添加一个“debug”部分，例如“myjs.js”将自动变为“myjs.debug.js”。
IgnoreScriptPath：是否忽略掉<asp:ScriptManager>标签中ScriptPath属性的定义。
 

3、<asp:ServiceReference>标签

    移除了GenerateProxy、OnScriptLoad和Type这三个鸡肋属性。留下的只有如下两个： 
    InlineScript：是否将这个Proxy内联到页面中，内联到页面中将省去一次HTTP连接，某种程度上将略微加快程序的初始化速度。
    Path：Web Service的文件路径。 
 
4、<AuthenticationService>标签
    Path：验证服务的文件路径。 
 
5、<ProfileService>标签
    Path：用户个性化服务的文件路径。
    LoadProperties：将内联到页面中的用户个性化属性。

6、对于<AuthenticationService>和<ProfileService>标签，似乎分别和AuthenticationServiceManager、ProfileServiceManager有关，同样将用于客户端Web Form模型中……