ASP.NET 4 和 Visual Studio 2010 Web 开发概述 1 — 核心服务

ASP.NET 4 和 Visual Studio 2010 Web 开发概述 1 - 核心服务

声明：本文是ASP.NET 白皮书 ASP.NET 4 and Visual Studio 2010 Web Development Overview 的阅读摘要，只是本人的学习记录，并非完整翻译，仅供参考，由于水平有限，有些翻译未必准确。点击下载PDF文档。

本文档提供了 ASP.NET 的许多新特性的概述，它们包含在 .NET Framework 4 和 Visual Studio 2010 中。

1. 核心服务

ASP.NET 4 引入了大量特性来增强核心 ASP.NET 服务，例如输出缓存和会话状态存储。

1) Web.config 文件重构

随着新特性的增加，如 Ajax、路由以及与 IIS 7 的交互，Web.config 文件包含的配置越来越多。在 .NET Framework 4 中，主要的配置元素已经移到 machine.config 文件中。这样 ASP.NET 4 应用程序中的 Web.config 文件可以是空的或只包含几行，即指定要针对哪个版本的框架的内容：

<? xml version ="1.0"? >
< configuration >
< system.web >
< compilation targetFramework ="4.0" />
</ system.web >
</ configuration >

2) 可扩展的输出缓存

以前版本的 ASP.NET 要求输出缓存必须要存储在内存中。

ASP.NET 4 提供了输出缓存的可扩展能力，可以创建自定义的输出缓存提供程序。输出缓存提供程序能够使用任何存储机制来持久化 HTML 内容。这样就为多种持久化机制创建自定义输出缓存成为可能，这些机制包括本地或远程磁盘，云存储，以及分布式缓存引擎。

定义继承自 System.Web.Caching.OutputCacheProvider 类型的类即可创建自定义输出缓存提供程序。然后配置 Web.config 文件中的 outputCache 元素，例如：

< caching >
< outputCache defaultProvider ="AspNetInternalProvider" >
< providers >
< add name ="DiskCache"
type ="Test.OutputCacheEx.DiskOutputCacheProvider, DiskCacheProvider" />
</ providers >
</ outputCache >

</ caching >

ASP.NET 4 默认使用内存中输出缓存，即 defaultProvider 属性设置的 AspNetInternalProvider。

另外，可以为每个控件和每个请求选择不同的输出缓存提供程序。例如：

<%@ OutputCache Duration="60" VaryByParam="None" providerName="DiskCache" %>

为 HTTP 请求指定不同的输出缓存需要在 Global.asax 文件中重写 GetOutputCacheProviderName 方法。例如：

public override string GetOutputCacheProviderName(HttpContext context)
{
if (context.Request.Path.EndsWith( "Advanced.aspx"))
return "DiskCache";
else
return base.GetOutputCacheProviderName(context);
}

使用这种扩展能力，可以追求更积极更智能的输出缓存策略，比如现在可以在内存中缓存最常访问的前10个页面，而更低流量的页面缓存在磁盘中。此外，还可以为呈现的页面缓存每个 vary-by 组合，但使用分布式缓存会导致内存消耗从前端 Web 服务器中卸载。

3) 自动启动的Web应用程序

一些 Web 应用程序需要在第一次请求时加载大量的数据或执行昂贵的初始化处理。之前要自己想办法。现在增加了一个新的具有可伸缩能力的特性，叫做自动启动（auto-start），当 ASP.NET 4 运行在 Windows Server 2008 R2 的 IIS 7.5 上时，它能直接解决这样的场景。自动启动为启动应用程序池、初始化 ASP.NET 应用程序以及接受 HTTP 请求提供了可控制的方法。

要使用自动启动特性，IIS 管理员需要设置 applicationHost.config 文件中的应用程序池：

< applicationpools >
< add name ="MyApplicationPool" startMode ="AlwaysRunning" />
</ applicationpools >

因为单个的应用程序池可以包含多个应用程序，所以需要在 applicationHost.config 文件中为单独的应用程序进行设定：

< sites >
< site name ="MySite" id ="1" >
< application path ="/"
serviceAutoStartEnabled ="true"
serviceAutoStartProvider ="PrewarmMyCache" >
<!-- Additional content -->
</ application >
</ site >

</ sites >

<!-- Additional content -->

< serviceautostartproviders >
< add name ="PrewarmMyCache"
type ="MyNamespace.CustomInitialization, MyLibrary" />
</ serviceautostartproviders >

当 IIS 7.5 服务器是冷启动的，或当单独的应用程序池回收的时候，IIS 7.5 会使用 applicationHost.config 文件中的信息来确定哪些 Web 应用程序需要自动启动。对每个标记为自动启动的应用程序，IIS 7.5 会发送请求给 ASP.NET 4来启动应用程序。ASP.NET 会实例化定义在 serviceAutoStartProvider 属性中的类型然后调用其公共的入口方法。

创建一个托管的自动启动类型要实现 IProcessHostPreloadClient 接口，例如：

public class CustomInitialization : System.Web.Hosting.IProcessHostPreloadClient
{
public void Preload( string[] parameters)
{
// Perform initialization.
}
}

运行在Preload 方法中的初始化代码返回之后，ASP.NET 应用程序就做好准备处理请求了。

4) 永久重定向

从旧的URL转向新URL的传统方法是使用 Response.Redirect 方法，这个方法发出 HTTP 302 Found（临时重定向）响应，这会导致额外的 HTTP 往返旅程（round trip）。

ASP.NET 4 添加了新的 RedirectPermanent 辅助方法，可发出 HTTP 301 Moved Permanently 响应，例如：

RedirectPermanent( "/newpath/foroldcontent.aspx");

搜索引擎和其他用户代理识别出永久重定向后会存储新URL，消除了不必要的往返旅程。

5) 缩小的会话状态

ASP.NET 提供两种跨 Web 群（Web Farm）的默认选项：一个是调用进程外会话状态服务器的会话状态提供程序，另一个是将数据存储在SQL Server中的会话状态提供程序。两个选项都涉及将状态信息发送到 Web 应用程序的工作者进程外部，会话状态必须要在发送前进行序列化。依赖于开发人员保存多少信息在会话状态中，序列化的数据可能会迅速变大。

ASP.NET 4 为两种进程外会话状态提供程序引入了新的压缩选项。当设置为 true 时，ASP.NET 会使用 System.IO.Compression.GZipStream 类压缩或解压缩序列化的会话状态。

< sessionState
mode ="SqlServer"
sqlConnectionString ="data source=dbserver;Initial Catalog=aspnetstate"
allowCustomSqlDatabase ="true"
compressionEnabled ="true"
/>

6) 扩展允许的URL范围

基于 NTFS 文件路径限制，旧版本的ASP.NET 限制 URL 路径长度为 260 个字符。在 ASP.NET 4 中，有选项来增强或减少这个限制。例如：

< httpRuntime maxUrlLength ="260" maxQueryStringLength ="2048" />

要允许更长或更短的路径（即URL中不包括协议、服务器名和查询字符串的部分），修改 maxUrlLength 即可。要允许更长或更短的查询字符串，修改 maxQueryStringLength 的值。

ASP.NET 4 还提供了检查 URL 包含字符的配置。当发现URL的路径部分中的无效字符时，ASP.NET 会拒绝请求并发出 HTTP 400 错误。旧版本限制了一组固定的字符，ASP.NET 4 可以自定义这些字符了：

< httpRuntime requestPathInvalidChars ="&lt;,>,*,%,&amp;,:,\,?" /&gt;

注意 ASP.NET 4 总量会拒绝包含 ASCII 码范围在 0x00 到 0x1F 之间的字符的 URL 路径。因为这些是定义在 RFC 2396 中的无效 URL 字符。在运行 IIS 6 或更高版本的 Windows Server 各个版本中，http.sys 协议设备驱动程序会自动地拒绝带有这些字符的 URL。

7) 可扩展的请求验证

ASP.NET 请求验证会搜索进来的 HTTP 请求数据中用于跨站点脚本（XSS，cross-site scripting）攻击的字符串。如果找到，请求验证会标出可疑脚本并返回错误。内置的请求验证仅当发现了最常见的XSS攻击字符串时都会错误。

在 ASP.NET 4 中，请求验证特性可以进行扩展了，这样可以使用自定义的请求验证逻辑。要扩展请求验证逻辑，可以创建继承自新的 System.Web.Util.RequestValidator 类型的类，然后配置应用程序使用自定义类型。例如：

< httpRuntime requestValidationType ="Samples.MyValidator, Samples" />

对每个请求，ASP.NET 都会调用自定义类型去处理每段进入的 HTTP 请求数据。进入的 URL，所有的 HTTP 头（cookies 和 自定义头），以及实体主体对自定义请求验证类都可拿来检查。这样的类定义如下所示：

public class CustomRequestValidation : RequestValidator
{
protected override bool IsValidRequestString(
HttpContext context, string value,
RequestValidationSource requestValidationSource,
string collectionKey,
out int validationFailureIndex)
{...}
}

8) 对象缓存和对象缓存扩展

从初次发布起，ASP.NET 就包含了强大的内存中对象缓存（System.Web.Caching.Cache）。缓存实现已经变得非常游行以至于它也被用于非 Web 应用程序。然而对于 Windows 窗体或 WPF 来说包含对 System.Web.dll 的引用而只是想使用 ASP.NET 对象缓存很不合适。

为了让所有应用程序都能用到缓存，.NET Framework 4 引入了新的程序集，新的全名空间，一些基类型，和具体的缓存实现。新的 System.Runtime.Caching.dll 程序集包含了 System.Runtime.Caching 全名空间中的新的缓存 API。全名空间包含两个核心的类集合：

• 抽象类型提供生成任何类型的自定义缓存实现的基础
• 一个具体的内存中对象缓存实现（System.Runtime.Caching.MemoryCache 类）

新的 MemoryCache 类接近于 ASP.NET 缓存，它和 ASP.NET 共享了许多内部缓存逻辑。尽管 System.Runtime.Caching 中的公共缓存 API 已经更新来支持自定义缓存的开发，如果你使用过 ASP.NET Cache 对象，你会发现在 API 中的概念是相似的。

下面的示例提供了新的缓存API是如何工作的思路，这个示例是为 Windows 窗体编写的，没有依赖于 System.Web.dll。

private void btnGet_Click( object sender, EventArgs e)
{
//Obtain a reference to the default MemoryCache instance.
//Note that you can create multiple MemoryCache(s) inside
//of a single application.
ObjectCache cache = MemoryCache.Default;

//In this example the cache is storing the contents of a file string
fileContents = cache[ "filecontents"] as string;

//If the file contents are not currently in the cache, then
//the contents are read from disk and placed in the cache.
if (fileContents == null)
{
//A CacheItemPolicy object holds all the pieces of cache
//dependency and cache expiration metadata related to a single
//cache entry.
CacheItemPolicy policy = new CacheItemPolicy();

//Build up the information necessary to create a file dependency.
//In this case we just need the file path of the file on disk.
List filePaths = new List();
filePaths.Add( "c:\\data.txt");

//In the new cache API, dependencies are called "change monitors".
//For this example we want the cache entry to be automatically expired
//if the contents on disk change. A HostFileChangeMonitor provides
//this functionality.
policy.ChangeMonitors.Add( new HostFileChangeMonitor(filePaths));

//Fetch the file's contents
fileContents = File.ReadAllText( "c:\\data.txt");

//And then store the file's contents in the cache
cache.Set( "filecontents", fileContents, policy);

}
MessageBox.Show(fileContents);
}

9) 可扩展的 HTML, URL, 和 HTTP 头编码

在 ASP.NET 4 中，可以为下列通用的文本编码任务创建自定义编码例程：

• HTML 编码
• URL 编码
• HTML 属性编码
• 编码出站（outbound）的 HTTP 头

通过从新的 System.Web.Util.HttpEncoder 类型派生，可以创建自定义编码器，然后配置 ASP.NET 使用这个自定义类型，例如：

< httpRuntime encoderType ="Samples.MyCustomEncoder, Samples" />

配置好之后，无论何时 System.Web.HttpUtility 或 System.Web.HttpServerUtility 类的公开编码方法被调用，ASP.NET 都会自动调用自定义编码实现。

10) 对单个工作者进程中独立应用程序的性能监视

为了在一个单独的服务器上能够运行更多的 Web 站点，许多主机在单个工作者进程中运行多个 ASP.NET 应用程序。然而，如果多个应用程序使用单个共享的工作者进程，对服务器管理员来说标识出有问题的独立应用程序是很困难的。

ASP.NET 4 调节了由 CLR 引入的新的资源监视功能。要启用这个功能，可以添加下列的 XML 配置片断到 aspnet.config 配置文件中：

<? xml version ="1.0" encoding ="UTF-8" ? >
< configuration >
< runtime >
< appDomainResourceMonitoring enabled ="true" />
</ runtime >

</ configuration >

注意 aspnet.config 文件位于 .NET Framework 的安装目录，不是 Web.config 文件。

启用之后，两个新的性能计数器在“ASP.NET 应用程序”性能分类中就可用了：% Managed Processor Time 和 Managed Memory Used。这两个性能计数器使用 CLR 新的应用程序域资源管理特性来追踪估算的 CPU 时间和单独的 ASP.NET 应用程序的托管内存利用。

11) 多目标

可以创建针对特定版本 .NET Framework 的应用程序。如果你显式地针对 .NET Framework 4，如果在 Web.config 文件包含了可选的元素，如对 system.codedom 的条目，这些元素必须是正确的对 .NET Framework 4 的。（如果没有显式地针对 .NET Framework 4，目标框架会进行推断）。示例：

< compilation targetFramework ="4.0" />

注意下列针对特定版本的 .NET Framework 的事项：

• 在 .NET Framework 4 应用程序池中，如果 Web.config 文件中没有包含 targetFramework 属性或者缺少 Web.config 文件，ASP.NET 生成系统会假设 .NET Framework 4 是目标。（你可能必须修改代码使应用程序运行在 .NET Framework 4 中）
• 如果你包含了 targetFramework 属性，如果 system.codeDom 元素定义在了 Web.config 文件中，这个文件必须包含针对 .NET Framework 4 的正确条目。
• 如果你正在使用 aspnet_compiler 命令预编译你的应用程序（例如在一个生成环境），你必须使用针对目标框架的正确版本的 aspnet_compiler 命令。
• 在运行时，编译器使用安装在计算机中的最新版本的框架程序集（当然在GAC中）。如果后来对框架做了更新（例如，假设安装了 4.1 版本），是能够使用更新版本框架中的特性的，即便 targetFramework 属性针对的是更低的版本（例如4.0）。（然而，在 VS2010 的设计时或使用 aspnet_compiler 命令时，使用框架的新特性会导致编译器错误）。