Notes of "ASP.NET 4 Beta 2 Breaking Changes"

Web.config中ControlRenderingCompatabilityVersion设置

修改了ASP.NET控件的一些标记，如果在VS2010中将2.0或3.5的程序进行升级，那么将会保留旧的规则。但是如果在IIS中将其设置成.NET Framework4，则将使用新的渲染模式。涉及到的有：

• Image和ImageButton控件不再输出border="0"属性。
• BaseValidator类以及验证控件默认情况下将不以红色字体显示。
• HtmlForm控件将不再输出name属性。
• Table控件将不再输出border="0"属性。
• 控件将不再为用户输入而设计，如果它们的Enabled设置为false也不会再写disabled="disabled"（比如，Label控件）。
  例如，下面的代码：
  <asp:Label ID="lbTextUnabled" Enabled="false" Text="This is a Label unabled!" runat="server"></asp:Label>
  <asp:Label ID="lbTextEnabled" Enabled="true" Text="This is a Label enabled!" runat="server"></asp:Label>
  <hr />
  <asp:Button ID="btnSubmitUnabled" Enabled="false" runat="server" Text="Submit Unabled"></asp:Button>
  <asp:Button ID="btnSubmitEnabled" Enabled="true" runat="server" Text="Submit Enabled"></asp:Button>
  
  将会替换为：
  <span id="MainContent_lbTextUnabled" class="aspNetDisabled">This is a Label unabled!</span>
  <span id="MainContent_lbTextEnabled">This is a Label enabled!</span>
  <hr />
  <input type="submit" name="ctl00$MainContent$btnSubmitUnabled" value="Submit Unabled" id="MainContent_btnSubmitUnabled" disabled="disabled" class="aspNetDisabled" />
  <input type="submit" name="ctl00$MainContent$btnSubmitEnabled" value="Submit Enabled" id="MainContent_btnSubmitEnabled" />
  

ClientIDMode改变（客户端ID的变化）

ASP.NET4默认允许你选择如何设定客户端ID。过去的版本在这里是设置ClientIDMode成“AutoID”，但ASP.NET4默认是“Predictable”模式。如果在VS2010中，升级2.0或3.5的程序，将会自动增加“”。如果在IIS中将其设置成.NET Framework4则需要手动添加来强制使用旧的规则，否则将使用新规则。

浏览器定义文件更新

浏览器定义文件进行了更新，删除了一些已经淘汰的浏览器，如：Netscape，增加了一些新型的浏览器，如Google Chrome以及Apple iPhone。

ASP.NET中，context.Request.Browser.Cookies = true的时候，是否一定可以利用客户端Cookies。如果回答不是，则询问：“MSDN中解释：获取一个值，该值指示浏览器是否支持 Cookie。”，你为何回答“不是”？（正确答案：不是，理由：Cookies值只能表示当前访问的浏览器，假设是IE8，则是指IE8是支持Cookies的，而不是指当前用户的计算机上的 IE8是否支持Cookies。（回答到这里+5分）HttpRequest的Browser属性是通过在应用程序中，或者在全局缓存中设置的 ×.BROWSERS文件里所设定的内容来加载的（ASP.NET 1.1则在Machine.config文件中有browserCaps配置节，但在ASP.NET2.0中被否定（但仍然可以使用）），当用户代理（IE/FireFox等浏览器）将自身的信息发送给浏览器时，将通过在BROWSERS中设置的正则表达式进行匹配（MATCH），如果匹配成功则加载对应的XML信息，并构造出HttpBrowserCompatibilies对象进行加载。而不是由用户浏览器发送当前的设置信息给服务器，来进行“设置”对应值的。）

• 什么是浏览器定义文件？答：一些关于各种浏览器的XML定义的文件，用于反应出该浏览器所具有的功能的描述文件。
• 参考链接1：http://msdn.microsoft.com/zh-cn/library/system.web.configuration.httpcapabilitiesbase.cookies%28VS.80%29.aspx
• 参考链接2：http://msdn.microsoft.com/zh-cn/library/3yekbd5b%28VS.80%29.aspx

现在默认的哈希算法是HMACSHA256

就像Form表单验证的Cookie和ViewState现在默认的哈希验证算法将变为：HMACSHA256，而之前的版本中是：HMACSHA1

<machineKey validation="SHA1" />

ASP.NET 4的相关配置错误

本节主要涉及了一些关于hotfix，详见“Configuration Errors Related to New ASP.NET 4 Root Configuration/Resolving These Issues”

HttpRequest.FilePath属性将不再包含在PathInfo的值

本节，看完示例应该就明白了。

/testapp/Action.mvc/SomeAction
  在早期版本的ASP.NET中，HttpRequest的一些属性值如下：
    HttpRequest.FilePath: /testapp/Action.mvc/SomeAction
    HttpRequest.PathInfo: (empty)
  在ASP.NET 4中，HttpRequest的一些属性值如下：
    HttpRequest.FilePath: /testapp/Action.mvc
    HttpRequest.PathInfo: SomeAction

在IIS7或者IIS7.5集成管道模式下，默认文档的事件处理程序可能不可用

在ASP.NET 4中，默认的form表单的action属性将会被设置成“""”（空）而不是“Default.aspx”。

    <form action="Default.aspx" />
    <form action="" />

如果action属性为空字符串，则IIS的DefaultDocumentModule对象将创建一个子请求到Default.aspx。
然而，这将导致托管代码与IIS7或者IIS7.5导致.aspx页面停止子请求。描述如下：

1. 一个form表单的action的值为""的.aspx页面发送到浏览器。
2. form表单做了一次回发。
3. 一个托管的HTTP模块（HttpModule）试图阅读form表单的内容，比如使用了Request.Form或者Request.Params。这将导致POST请求被读入托管内存中。因此任何本地代码模块（native code module）在IIS7或则IIS7.5集成管道模式下，都无法阅读POST请求的数据。
4. IISDefaultDocumentModule对象将运行并创建Default.aspx。然而因为POST的数据已经被托管代码读取，因此在子请求中将不可用。
5. 然后就到了HTTP管道运行子请求，.aspx页面执行阶段的时候。
6. 因为没有了POST的数据，因此没有form变量（表单域的值），也没有ViewState，因此也没有办法在.aspx页面执行的时候决定哪个事件（或其他别的）被触发（Raised）。

避免以上问题的方法有：

• 标识出HTTP模块访问默认文档请求的时候，决定请求内容（request's entity body）是否只允许被托管请求读取。在IIS7或者IIS7.5集成模式下，HTTP模块可以被标识为是否只允许托管请求访问，在system.webServer/modules节点下增加
      precondition="managedHandler"
  这会强制该模块只针对发送给托管 (ASP.NET) 处理程序的请求运行。因为请求的action是""，因此它不会执行托管模块，因此也就不会使POST的数据不可用了。
• 但是，如果HTTP模块必须针对所有类型的请求（静态文件，没有指明具体文件的URL的DefaultDocumentModule对象，以及托管请求等）。那么将action设置为非空字符串即可，比如“Default.aspx”。

ASP.NET代码访问安全性（CAS）的一些改变

之前一部分“部分信赖（partial-trust）”的代码依赖于全局程序集缓存（GAC）的代码将有可能遭遇莫名其妙的错误。
对于ASP.NET 4应用程序，如果你要以旧的代码访问安全性策略来做的话，可以设置如下语句：

<trust level= "Medium" legacyCasModel="true" />

因为代码访问安全性的问题，以后就不可以在非web（non-web）应用程序中引用System.Web.*下的代码了，它们都要求有AspNetHostingPermission权限。System.Web.HttpUtility也相应地改动了命名空间，为System.Web.ClientServices.*。而HtmlEncode和HtmlDecode则移动到System.Net.WebUtility类下。

相关链接：

• Using Code Access Security in ASP.NET Applications

输出缓存改变Vary * HTTP Header

主要是针对一些在Location="ServerAndClient"情况下的输出缓存是否输出"Vary *"的问题。

相关链接：

• 详见原文
• Vary *(www.w3.org)

System.Web.Security里关于Passport的类型都已标注为[已过时]

这里的Passport也就是指LiveID。其相关的方法将逐渐不被支持。五个类型全部标注为已过时。

原文链接