本文档概述了 the.NET Framework 4 和 Visual Studio 2010 中包含的 ASP.NET 的许多新功能。
Contents
核心服务
Web.config 文件重构
可扩展输出缓存
自动启动 Web 应用程序
永久重定向页面
正在收缩会话状态
扩展允许 URL 的范围
可扩展请求验证
对象缓存和对象缓存扩展性
可扩展的 HTML、URL 和 HTTP 标头编码
单个工作进程中各个应用程序的性能监视
多目标
Ajax
jQuery 随附于 Web Forms 和 MVC
内容分发网络支持
ScriptManager 显式脚本
Web Forms
使用 Page.MetaKeywords 和 Page.MetaDescription 属性设置元标记
为单个控件启用视图状态
对浏览器功能的更改
ASP.NET 4 中的路由
设置客户端 ID
在数据控件中保留行选择
ASP.NET 图表控件
使用 QueryExtender 控件筛选数据
Html 编码的代码表达式
项目模板更改
CSS 改进
隐藏隐藏字段周围的 div 元素
呈现模板化控件的外部表
ListView 控件增强功能
CheckBoxList 和 RadioButtonList 控件增强功能
菜单控件改进
向导和 CreateUserWizard 控件 56
ASP.NET MVC
区域支持
数据注释属性验证支持
模板化帮助程序
动态数据
为现有项目启用动态数据
声明性 DynamicDataManager 控件语法
实体模板
URL 和电子邮件地址的新字段模板
使用 DynamicHyperLink 控件创建链接
支持数据模型中的继承
仅支持实体框架 (多对多关系)
用于控制显示和支持枚举的新属性
增强了对筛选器的支持
Visual Studio 2010 Web 开发改进
改进了 CSS 兼容性
HTML 和 JavaScript 代码段
JavaScript IntelliSense 增强功能
使用 Visual Studio 2010 部署 Web 应用程序
Web 打包
Web.config 转换
数据库部署
Web 应用程序的一键式发布
资源
核心服务
ASP.NET 4 引入了许多改进核心 ASP.NET 服务的功能,例如输出缓存和会话状态存储。
Web.config 文件重构
Web.config
过去几个版本的 .NET Framework,包含 Web 应用程序的配置的文件已大幅增长,因为添加了新功能,例如 Ajax、路由和与 IIS 7 的集成。 这使得在没有 Visual Studio 之类的工具的情况下配置或启动新的 Web 应用程序变得更加困难。 在 .net Framework 4 中,主要配置元素已移动到 machine.config
文件中,应用程序现在将继承这些设置。 这允许 Web.config
ASP.NET 4 应用程序中的文件为空或仅包含以下行,这些行指定 Visual Studio 应用程序面向的框架版本:
<?xml version="1.0"?>
<configuration>
<system.web>
<compilation targetFramework="4.0" />
</system.web>
</configuration>
可扩展输出缓存
自 ASP.NET 1.0 发布以来,输出缓存使开发人员能够将生成的页面、控件和 HTTP 响应的输出存储在内存中。 在后续的 Web 请求中,ASP.NET 可以从内存中检索生成的输出,而不是从头开始重新生成输出,从而更快地提供内容。 但是,此方法有一个限制 - 生成的内容始终必须存储在内存中,在遇到大量流量的服务器上,输出缓存消耗的内存可以与 Web 应用程序其他部分的内存需求竞争。
ASP.NET 4 向输出缓存添加了一个扩展点,使你能够配置一个或多个自定义输出缓存提供程序。 输出缓存提供程序可以使用任何存储机制来保留 HTML 内容。 这样就可以为各种持久性机制创建自定义输出缓存提供程序,这些机制可能包括本地或远程磁盘、云存储和分布式缓存引擎。
创建自定义 output-cache 提供程序作为派生自新的 System.Web.Caching.OutputCacheProvider 类型的类。 然后,可以使用 outputCache 元素的新 providers 子节在 Web.config
文件中配置提供程序,如以下示例所示:
<caching>
<outputCache defaultProvider="AspNetInternalProvider">
<providers>
<add name="DiskCache"
type="Test.OutputCacheEx.DiskOutputCacheProvider, DiskCacheProvider"/>
</providers>
</outputCache>
</caching>
默认情况下,在 ASP.NET 4 中,所有 HTTP 响应、呈现的页面和控件都使用内存中输出缓存,如前面的示例所示,其中 defaultProvider 属性设置为 AspNetInternalProvider。 可以通过为 defaultProvider 指定不同的提供程序名称,更改用于 Web 应用程序的默认输出缓存提供程序。
此外,可以为每个控件和每个请求选择不同的输出缓存提供程序。 为不同的 Web 用户控件选择其他输出缓存提供程序的最简单方法是在控件指令中使用新的 providerName 属性以声明方式执行此操作,如以下示例所示:
<%@ OutputCache Duration="60" VaryByParam="None" providerName="DiskCache" %>
为 HTTP 请求指定不同的输出缓存提供程序需要更多的工作。 无需以声明方式指定提供程序,而是重写 文件中的新 GetOuputCacheProviderName 方法 Global.asax
,以编程方式指定要用于特定请求的提供程序。 以下示例演示如何执行此操作。
public override string GetOutputCacheProviderName(HttpContext context)
{
if (context.Request.Path.EndsWith("Advanced.aspx"))
return "DiskCache";
else
return base.GetOutputCacheProviderName(context);
}
通过向 ASP.NET 4 添加输出缓存提供程序扩展性,现在可以为网站采用更主动、更智能的输出缓存策略。 例如,现在可以在内存中缓存站点的“前 10 个”页,同时缓存磁盘上流量较低的页面。 或者,可以缓存呈现页面的每个变化组合,但使用分布式缓存,以便从前端 Web 服务器卸载内存消耗。
自动启动 Web 应用程序
某些 Web 应用程序需要在为第一个请求提供服务之前加载大量数据或执行昂贵的初始化处理。 在早期版本的 ASP.NET 中,对于这些情况,必须设计自定义方法来“唤醒”ASP.NET 应用程序,然后在文件中 的 Application_Load 方法 Global.asax
期间运行初始化代码。
当 ASP.NET 4 在 Windows Server 2008 R2 上的 IIS 7.5 上运行时,可以使用名为 “自动启动 ”的新可伸缩性功能,该功能可直接解决此方案。 自动启动功能提供了一种受控方法,用于启动应用程序池、初始化 ASP.NET 应用程序,然后接受 HTTP 请求。
注意
适用于 IIS 7.5 的 IIS 应用程序 Warm-Up 模块
IIS 团队已发布适用于 IIS 7.5 的应用程序 Warm-Up 模块的第一个 beta 测试版本。 这使得预热应用程序比前面描述的要容易。 无需编写自定义代码,而是指定要在 Web 应用程序接受来自网络的请求之前执行的资源的 URL。 如果将 IIS 应用程序池配置为 AlwaysRunning) 并且 IIS 工作进程回收,则此预热发生在 IIS 服务启动期间 (。 在回收期间,旧的 IIS 工作进程将继续执行请求,直到新生成的工作进程完全预热,以便应用程序不会因无特权缓存而遇到中断或其他问题。 请注意,此模块适用于任何版本的 ASP.NET,从版本 2.0 开始。
有关详细信息,请参阅 IIS.net 网站上的 应用程序预热 。 有关演示如何使用预热功能的演练,请参阅 IIS.net 网站上的 IIS 7.5 应用程序 Warm-Up 模块入门。
若要使用自动启动功能,IIS 管理员使用 文件中的以下配置将 IIS 7.5 中的 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 应用程序。 对于标记为自动启动的每个应用程序,IIS7.5 向 ASP.NET 4 发送请求,以在应用程序暂时不接受 HTTP 请求的状态启动应用程序。 当它处于此状态时,ASP.NET 实例化 serviceAutoStartProvider 属性 (定义的类型,如前面的示例所示,) 并调用其公共入口点。
通过实现 IProcessHostPreloadClient 接口,创建具有必要入口点的托管自动启动类型,如以下示例所示:
public class CustomInitialization : System.Web.Hosting.IProcessHostPreloadClient
{
public void Preload(string[] parameters)
{
// Perform initialization.
}
}
初始化代码在 Preload 方法中运行且 方法返回后,ASP.NET 应用程序已准备好处理请求。
在 IIS .5 和 ASP.NET 4 中添加了自动启动功能后,你现在有了一种明确定义的方法,用于在处理第一个 HTTP 请求之前执行昂贵的应用程序初始化。 例如,可以使用新的自动启动功能初始化应用程序,然后向负载均衡器发出信号,指示应用程序已初始化并准备好接受 HTTP 流量。
永久重定向页面
Web 应用程序中的常见做法是随时间推移而移动页面和其他内容,这可能导致搜索引擎中过时链接的积累。 在 ASP.NET 中,开发人员传统上使用 Response.Redirect 方法将请求转发到新 URL,从而处理对旧 URL 的请求。 但是, 重定向 方法会发出 HTTP 302 Found (临时重定向) 响应,这会导致用户尝试访问旧 URL 时出现额外的 HTTP 往返。
ASP.NET 4 添加了一个新的 RedirectPermanent 帮助程序方法,该方法可以轻松发出 HTTP 301 已移动永久响应,如以下示例所示:
RedirectPermanent("/newpath/foroldcontent.aspx");
识别永久重定向的搜索引擎和其他用户代理将存储与内容关联的新 URL,这消除了浏览器为临时重定向所做的不必要的往返行程。
正在收缩会话状态
ASP.NET 提供了两个用于跨 Web 场存储会话状态的默认选项:一个是调用进程外会话状态服务器的会话状态提供程序,一个是用于在 Microsoft SQL Server 数据库中存储数据的会话状态提供程序。 由于这两个选项都涉及将状态信息存储在 Web 应用程序的工作进程之外,因此会话状态在发送到远程存储之前必须对其进行序列化。 根据开发人员在会话状态中保存的信息量,序列化数据的大小可能会变得很大。
ASP.NET 4 为这两种类型的进程外会话状态提供程序引入了新的压缩选项。 将以下示例中显示的 compressionEnabled 配置选项设置为 true 时,ASP.NET 将使用.NET Framework System.IO.Compression.GZipStream 类压缩 (并解压缩) 序列化会话状态。
<sessionState
mode="SqlServer"
sqlConnectionString="data source=dbserver;Initial Catalog=aspnetstate"
allowCustomSqlDatabase="true"
compressionEnabled="true"
/>
将新 属性简单添加到 Web.config
文件后,Web 服务器上具有备用 CPU 周期的应用程序可以实现序列化会话状态数据大小的大幅减少。
扩展允许 URL 的范围
ASP.NET 4 引入了用于扩展应用程序 URL 大小的新选项。 根据 NTFS 文件路径限制,以前版本的 ASP.NET URL 路径长度限制为 260 个字符。 在 ASP.NET 4 中,可以选择使用两个新的 httpRuntime 配置属性,根据应用程序) 此限制增加或减少 (。 以下示例演示这些新属性。
<httpRuntime maxUrlLength="260" maxQueryStringLength="2048" />
若要允许较长或较短的路径 (URL 中不包含协议、服务器名称和查询字符串) 部分,请修改 maxUrlLength 属性。 若要允许更长或更短的查询字符串,请修改 maxQueryStringLength 属性的值。
ASP.NET 4 还允许配置 URL 字符检查使用的字符。 当 ASP.NET 在 URL 的路径部分发现无效字符时,它会拒绝请求并发出 HTTP 400 错误。 在以前版本的 ASP.NET 中,URL 字符检查仅限于一组固定字符。 在 ASP.NET 4 中,可以使用 httpRuntime 配置元素的新 requestPathInvalidCharacters 属性自定义有效字符集,如以下示例所示:
<httpRuntime requestPathInvalidCharacters="<,>,*,%,&,:,\,?" />
默认情况下, requestPathInvalidCharacters 属性将八个字符定义为无效。 (默认情况下,在分配给 requestPathInvalidCharacters 的字符串中,将编码小于 (<) 、大于 (>) 和 ampsand (&) 字符,因为 Web.config
该文件是 XML 文件。) 可以根据需要自定义无效字符集。
注意
注意 ASP.NET 4 始终拒绝包含 ASCII 范围(0x00 0x1F)中的字符的 URL 路径,因为这些是 IETF (http://www.ietf.org/rfc/rfc2396.txt) RFC 2396 中定义的无效 URL 字符。 在运行 IIS 6 或更高版本的 Windows Server 上,http.sys 协议设备驱动程序会自动拒绝包含这些字符的 URL。
可扩展请求验证
ASP.NET 请求验证在传入的 HTTP 请求数据中搜索通常用于跨站点脚本 (XSS) 攻击的字符串。 如果找到潜在的 XSS 字符串,请求验证会标记可疑字符串并返回错误。 仅当内置请求验证找到 XSS 攻击中使用的最常见字符串时,才会返回错误。 以前尝试使 XSS 验证更具攻击性,导致误报过多。 但是,客户可能需要更激进的请求验证,或者相反,可能想要有意放宽对特定页面或特定请求类型的 XSS 检查。
在 ASP.NET 4 中,请求验证功能已变得可扩展,以便可以使用自定义请求验证逻辑。 若要扩展请求验证,请创建一个派生自新的 System.Web.Util.RequestValidator 类型的类,并将文件) httpRuntime 部分中 Web.config
的应用程序 (配置为使用自定义类型。 以下示例演示如何配置自定义请求验证类:
<httpRuntime requestValidationType="Samples.MyValidator, Samples" />
新的 requestValidationType 属性需要一个标准.NET Framework类型标识符字符串,该字符串指定提供自定义请求验证的类。 对于每个请求,ASP.NET 调用自定义类型来处理传入 HTTP 请求数据的每一段。 传入 URL、所有 HTTP 标头 (cookie 和自定义标头) ,以及实体正文都可供自定义请求验证类检查,如以下示例所示:
public class CustomRequestValidation : RequestValidator
{
protected override bool IsValidRequestString(
HttpContext context, string value,
RequestValidationSource requestValidationSource,
string collectionKey,
out int validationFailureIndex)
{...}
}
如果不想检查一段传入的 HTTP 数据,请求验证类可以回退,让 ASP.NET 默认请求验证只需调用 base 即可运行。IsValidRequestString。
对象缓存和对象缓存扩展性
自第一次发布以来,ASP.NET 包含一个功能强大的内存中对象缓存 (System.Web.Caching.Cache) 。 缓存实现非常受欢迎,以至于已在非 Web 应用程序中使用。 但是,Windows 窗体或 WPF 应用程序为了能够使用 ASP.NET 对象缓存而包含对 System.Web.dll
的引用会很尴尬。
为了使缓存适用于所有应用程序,.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 中找到熟悉的概念。
深入讨论新的 MemoryCache 类和支持基 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);
}
可扩展的 HTML、URL 和 HTTP 标头编码
在 ASP.NET 4 中,可以为以下常见文本编码任务创建自定义编码例程:
- HTML 编码。
- URL 编码。
- HTML 属性编码。
- 对出站 HTTP 标头进行编码。
可以通过从新的 System.Web.Util.HttpEncoder 类型派生,然后将 ASP.NET 配置为使用文件的 httpRuntime 节 Web.config
中的自定义类型来创建自定义编码器,如以下示例所示:
<httpRuntime encoderType="Samples.MyCustomEncoder, Samples" />
配置自定义编码器后,每当调用 System.Web.HttpUtility 或 System.Web.HttpServerUtility 类的公共编码方法时,ASP.NET 会自动调用自定义 编码 实现。 这样,Web 开发团队的一部分可以创建自定义编码器来实现激进字符编码,而 Web 开发团队的其余人员则继续使用公共 ASP.NET 编码 API。 通过在 httpRuntime 元素中集中配置自定义编码器,可以保证来自公共 ASP.NET 编码 API 的所有文本编码调用都通过自定义编码器路由。
单个工作进程中各个应用程序的性能监视
为了增加可在单个服务器上托管的网站数,许多主机托管程序在单个工作进程中运行多个 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
文件。
启用 appDomainResourceMonitoring 功能后,“ASP.NET 应用程序”性能类别中提供了两个新的性能计数器: “托管处理器时间百分比 ”和 “已使用托管内存”。 这两个性能计数器都使用新的 CLR 应用程序域资源管理功能来跟踪单个 ASP.NET 应用程序的估计 CPU 时间和托管内存利用率。 因此,ASP.NET 4,管理员现在可以更精细地了解在单个工作进程中运行的单个应用程序的资源消耗情况。
多目标
可以创建面向特定版本的.NET Framework的应用程序。 在 ASP.NET 4 中,文件的编译元素Web.config
中的新属性允许以 .NET Framework 4 及更高版本为目标。 如果显式面向.NET Framework 4,并且如果在文件中包含可选元素Web.config
(如 system.codedom 的条目),则这些元素对于.NET Framework 4 必须正确。 (如果不显式定位.NET Framework 4,则从文件中缺少条目Web.config
推断出目标框架。)
以下示例演示如何在文件的编译元素Web.config
中使用 targetFramework 属性。
<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 命令。 使用 .NET Framework 2.0 (%WINDIR%\Microsoft.NET\Framework\v2.0.50727) 随附的编译器针对 .NET Framework 3.5 及更早版本进行编译。 使用 .NET Framework 4 附带的编译器编译使用该框架或使用更高版本创建的应用程序。
- 在运行时,编译器使用安装在计算机上的最新框架程序集 (,因此安装在 GAC) 中。 例如,如果稍后对框架 (进行了更新,) 安装了假设的版本 4.1,则即使 targetFramework 属性面向较低版本的 ((如 4.0) ),你仍可以使用较新版本的框架中的功能。 (但是,在 Visual Studio 2010 中设计时或使用 aspnet_compiler 命令时,使用框架的较新功能将导致编译器错误) 。
Ajax
jQuery 随附Web Forms和 MVC
适用于 Web Forms 和 MVC 的 Visual Studio 模板都包含开源 jQuery 库。 创建新网站或项目时,将创建包含以下 3 个文件的 Scripts 文件夹:
- jQuery-1.4.1.js – jQuery 库的人工可读、未缩小的版本。
- jQuery-14.1.min.js – jQuery 库的缩小版本。
- jQuery-1.4.1-vsdoc.js – jQuery 库的 Intellisense 文档文件。
在开发应用程序时包括 jQuery 的未缩小版本。 包括适用于生产应用程序的 jQuery 的缩小版本。
例如,以下Web Forms页演示了如何使用 jQuery 将 ASP.NET TextBox 控件的背景色更改为具有焦点时为黄色。
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="ShowjQuery.aspx.cs" Inherits="ShowjQuery" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>Show jQuery</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:TextBox ID="txtFirstName" runat="server" />
<br />
<asp:TextBox ID="txtLastName" runat="server" />
</div>
</form>
<script src="Scripts/jquery-1.4.1.js" type="text/javascript"></script>
<script type="text/javascript">
$("input").focus( function() { $(this).css("background-color", "yellow"); });
</script>
</body>
</html>
内容分发网络支持
借助 Microsoft Ajax 内容分发网络 (CDN) ,可以轻松地将 ASP.NET Ajax 和 jQuery 脚本添加到 Web 应用程序。 例如,只需将指向 Ajax.microsoft.com 的标记添加到页面, <script>
即可开始使用 jQuery 库,如下所示:
<script src="https://ajax.aspnetcdn.com/ajax/jquery/jquery-1.4.2.js" type="text/javascript"></script>
通过利用 Microsoft Ajax CDN,可以显著改进 Ajax 应用程序的性能。 Microsoft Ajax CDN 的内容缓存在世界各地的服务器上。 此外,Microsoft Ajax CDN 使浏览器可以对位于不同域的网站重用缓存的 JavaScript 文件。
如果需要使用安全套接字层为网页提供服务,Microsoft Ajax 内容分发网络支持 SSL (HTTPS) 。
在 CDN 不可用时实现回退。 测试回退。
若要了解有关 Microsoft Ajax CDN 的详细信息,请访问以下网站:
https://www.asp.net/ajaxlibrary/CDN.ashx
ASP.NET ScriptManager 支持 Microsoft Ajax CDN。 只需设置一个属性 EnableCdn 属性,即可从 CDN 检索所有 ASP.NET 框架 JavaScript 文件:
<asp:ScriptManager ID="sm1" EnableCdn="true" runat="server" />
将 EnableCdn 属性设置为值 true 后,ASP.NET 框架将从 CDN 检索所有 ASP.NET 框架 JavaScript 文件,包括用于验证的所有 JavaScript 文件和 UpdatePanel。 设置此属性可能会对 Web 应用程序的性能产生巨大影响。
可以使用 WebResource 属性为自己的 JavaScript 文件设置 CDN 路径。 新的 CdnPath 属性指定将 EnableCdn 属性设置为值 true 时使用的 CDN 的路径:
[assembly: WebResource("Foo.js", "application/x-javascript", CdnPath = "http://foo.com/foo/bar/foo.js")]
ScriptManager 显式脚本
过去,如果使用 ASP.NET ScriptManger,则需要加载整个整体式 ASP.NET Ajax 库。 利用新的 ScriptManager.AjaxFrameworkMode 属性,可以准确控制加载 ASP.NET Ajax 库的哪些组件,并仅加载所需的 ASP.NET Ajax 库的组件。
ScriptManager.AjaxFrameworkMode 属性可以设置为以下值:
- 已启用 -- 指定 ScriptManager 控件自动包含 MicrosoftAjax.js 脚本文件,该文件是每个核心框架脚本 (旧行为) 的组合脚本文件。
- 已禁用 -- 指定禁用所有 Microsoft Ajax 脚本功能,并且 ScriptManager 控件不会自动引用任何脚本。
- 显式 -- 指定将显式包含对页面所需的单个框架核心脚本文件的脚本引用,以及将包含对每个脚本文件所需的依赖项的引用。
例如,如果将 AjaxFrameworkMode 属性设置为值 Explicit,则可以指定所需的特定 ASP.NET Ajax 组件脚本:
<asp:ScriptManager ID="sm1" AjaxFrameworkMode="Explicit" runat="server">
<Scripts>
<asp:ScriptReference Name="MicrosoftAjaxCore.js" />
<asp:ScriptReference Name="MicrosoftAjaxComponentModel.js" />
<asp:ScriptReference Name="MicrosoftAjaxSerialization.js" />
<asp:ScriptReference Name="MicrosoftAjaxNetwork.js" />
</Scripts>
</asp:ScriptManager>
Web 窗体
自 ASP.NET 1.0 发布以来,Web Forms一直是 ASP.NET 中的核心功能。 ASP.NET 4 已在此领域进行了许多增强,包括:
- 设置 元 标记的功能。
- 更好地控制视图状态。
- 使用浏览器功能的更简单方法。
- 支持将 ASP.NET 路由与 Web Forms 配合使用。
- 更好地控制生成的 ID。
- 在数据控件中保留所选行的功能。
- 对 FormView 和 ListView 控件中呈现的 HTML 进行更多控制。
- 对数据源控件的筛选支持。
使用 Page.MetaKeywords 和 Page.MetaDescription 属性设置元标记
ASP.NET 4 向 Page 类添加两个属性 :MetaKeywords 和 MetaDescription。 这两个属性表示页面中相应的 元 标记,如以下示例所示:
<head id="Head1" runat="server">
<title>Untitled Page</title>
<meta name="keywords" content="These, are, my, keywords" />
<meta name="description" content="This is the description of my page" />
</head>
这两个属性的工作方式与页面的 Title 属性的工作方式相同。 它们遵循以下规则:
- 如果 head 元素中没有与属性名称 (即 Page.MetaKeywords 的 name=“keywords”和 Page.MetaDescription 的 name=“description”相匹配的元标记,这意味着尚未) 设置这些属性,则呈现页面时会将元标记添加到页面中。
- 如果已有具有这些名称的 元 标记,则这些属性充当现有标记内容的 get 和 set 方法。
可以在运行时设置这些属性,以便从数据库或其他源获取内容,并动态设置标记以描述特定页面的用途。
还可以在Web Forms页标记顶部的 @ Page 指令中设置 Keywords 和 Description 属性,如以下示例所示:
<%@ Page Language="C#" AutoEventWireup="true"
CodeFile="Default.aspx.cs"
Inherits="_Default"
Keywords="These, are, my, keywords"
Description="This is a description" %>
如果已在页面中声明任何) ,这将替代 (元 标记内容。
description 元 标记的内容用于改进 Google 中的搜索列表预览。 (有关详细信息,请参阅 Google Webmaster Central 博客上的 使用元描述改进代码段 。) Google 和 Windows Live Search 不对任何内容使用关键字的内容,但其他搜索引擎可能也未使用关键字的内容。
这些新属性是一个简单的功能,但它们使你无需手动添加这些属性,也无需编写自己的代码来创建 元 标记。
为单个控件启用视图状态
默认情况下,为页面启用视图状态,因此页面上的每个控件都可能会存储视图状态,即使应用程序不需要它。 视图状态数据包含在页面生成的标记中,并增加了将页面发送到客户端并发布回页所需的时间。 如果存储的视图状态超出所需,可能会导致性能显著下降。 在早期版本的 ASP.NET 中,开发人员可以禁用单个控件的视图状态以减小页面大小,但必须对单个控件显式执行此操作。 在 ASP.NET 4 中,Web 服务器控件包含 ViewStateMode 属性,该属性允许你默认禁用视图状态,然后仅为页面中需要它的控件启用它。
ViewStateMode 属性采用具有三个值的枚举:Enabled、Disabled 和 Inherit。 “已启用” 为该控件和设置为 “继承 ”或未设置任何内容的任何子控件启用视图状态。 Disabled 禁用视图状态, Inherit 指定控件使用父控件中的 ViewStateMode 设置。
以下示例演示 ViewStateMode 属性的工作原理。 以下页面中控件的标记和代码包括 ViewStateMode 属性的值:
<form id="form1" runat="server">
<script runat="server">
protected override void OnLoad(EventArgs e) {
if (!IsPostBack) {
label1.Text = label2.Text = "[DynamicValue]";
}
base.OnLoad(e);
}
</script>
<asp:PlaceHolder ID="PlaceHolder1" runat="server" ViewStateMode="Disabled">
Disabled: <asp:Label ID="label1" runat="server" Text="[DeclaredValue]" /><br />
<asp:PlaceHolder ID="PlaceHolder2" runat="server" ViewStateMode="Enabled">
Enabled: <asp:Label ID="label2" runat="server" Text="[DeclaredValue]" />
</asp:PlaceHolder>
</asp:PlaceHolder>
<hr />
<asp:button ID="Button1" runat="server" Text="Postback" />
<%-- Further markup here --%>
可以看到,代码禁用 PlaceHolder1 控件的视图状态。 子 label1 控件继承此属性值 (Inherit 是 controls.) 的 ViewStateMode 的默认值,因此不保存任何视图状态。 在 PlaceHolder2 控件中, ViewStateMode 设置为 Enabled,因此 label2 继承此属性并保存视图状态。 首次加载页面时,两个 Label 控件的 Text 属性都设置为字符串“[DynamicValue]”。
这些设置的效果是,当页面首次加载时,浏览器中会显示以下输出:
禁用 : [DynamicValue]
启用:[DynamicValue]
但是,在回发后,将显示以下输出:
禁用 : [DeclaredValue]
启用:[DynamicValue]
label1 控件 (其 ViewStateMode 值设置为 Disabled) 未在代码中保留它设置为的值。 但是,label2 控件 (其 ViewStateMode 值设置为 Enabled) 已保留其状态。
还可以在 @ Page 指令中设置 ViewStateMode,如以下示例所示:
<%@ Page Language="C#" AutoEventWireup="true"
CodeBehind="Default.aspx.cs"
Inherits="WebApplication1._Default"
ViewStateMode="Disabled" %>
Page 类只是另一个控件;它充当页中所有其他控件的父控件。 对于 Page 的实例,ViewStateMode 的默认值为 Enabled。 由于控件默认为 Inherit,因此除非在页面或控件级别设置 ViewStateMode,否则控件将继承 Enabled 属性值。
ViewStateMode 属性的值确定是否仅在 EnableViewState 属性设置为 true 时才保持视图状态。 如果 EnableViewState 属性设置为 false,则即使 ViewStateMode 设置为 Enabled,视图状态也不会保持。
此功能的一个良好用途是母版页中的 ContentPlaceHolder 控件,你可以在其中将母版页的 ViewStateMode 设置为 Disabled ,然后为包含需要视图状态的控件的 ContentPlaceHolder 控件单独启用它。
对浏览器功能的更改
ASP.NET 通过使用称为浏览器功能的功能来确定用户用于浏览站点 的浏览器功能。 浏览器功能由 HttpBrowserCapabilities 对象表示, (Request.Browser 属性) 公开。 例如,可以使用 HttpBrowserCapabilities 对象来确定当前浏览器的类型和版本是否支持特定版本的 JavaScript。 或者,可以使用 HttpBrowserCapabilities 对象来确定请求是否源自移动设备。
HttpBrowserCapabilities 对象由一组浏览器定义文件驱动。 这些文件包含有关特定浏览器的功能的信息。 在 ASP.NET 4 中,这些浏览器定义文件已更新为包含最近引入的浏览器和设备的信息,如 Google Chrome、Motion BlackBerry 智能手机研究以及 Apple iPhone。
以下列表显示了新的浏览器定义文件:
- blackberry.browser
- chrome.browser
- Default.browser
- firefox.browser
- gateway.browser
- generic.browser
- ie.browser
- iemobile.browser
- iphone.browser
- opera.browser
- safari.browser
使用浏览器功能提供程序
在 ASP.NET 版本 3.5 Service Pack 1 中,可以通过以下方式定义浏览器的功能:
在计算机级别,可以在以下文件夹中创建或更新
.browser
XML 文件:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers
定义浏览器功能后,从 Visual Studio 命令提示符运行以下命令,以便重新生成浏览器功能程序集并将其添加到 GAC:
aspnet_regbrowsers.exe -I c
对于单个应用程序,可以在应用程序的
App_Browsers
文件夹中创建一个.browser
文件。
这些方法要求更改 XML 文件,对于计算机级更改,必须在运行 aspnet_regbrowsers.exe 进程后重启应用程序。
ASP.NET 4 包括一项称为 浏览器功能提供程序的功能。 顾名思义,这允许你构建一个提供程序,而该提供程序又允许你使用自己的代码来确定浏览器功能。
在实践中,开发人员通常不定义自定义浏览器功能。 浏览器文件很难更新,更新它们的过程相当复杂,文件的 XML 语法 .browser
可能很难使用和定义。 如果存在通用的浏览器定义语法、包含最新浏览器定义的数据库,甚至是此类数据库的 Web 服务,则会使此过程变得容易得多。 新的浏览器功能提供程序功能使这些方案对第三方开发人员成为可能和实用。
使用新的 ASP.NET 4 浏览器功能提供程序功能有两种main方法:扩展 ASP.NET 浏览器功能定义功能,或完全替换它。 以下部分首先介绍了如何替换该功能,然后介绍如何扩展该功能。
替换 ASP.NET 浏览器功能
若要完全替换 ASP.NET 浏览器功能定义功能,请执行以下步骤:
创建派生自 HttpCapabilitiesProvider 并重写 GetBrowserCapabilities 方法的提供程序类,如以下示例所示:
public class CustomProvider : HttpCapabilitiesProvider { public override HttpBrowserCapabilities GetBrowserCapabilities(HttpRequest request) { HttpBrowserCapabilities browserCaps = new HttpBrowserCapabilities(); Hashtable values = new Hashtable(180, StringComparer.OrdinalIgnoreCase); values[String.Empty] = request.UserAgent; values["browser"] = "MyCustomBrowser"; browserCaps.Capabilities = values; return browserCaps; } }
此示例中的代码创建一个新的 HttpBrowserCapabilities 对象,仅指定名为 browser 的功能,并将该功能设置为 MyCustomBrowser。
向应用程序注册提供程序。
若要将提供程序与应用程序一起使用,必须将提供程序属性添加到 或
Machine.config
文件中的Web.config
browserCaps 节。 (还可以在应用程序中特定目录 的位置 元素中定义提供程序属性,例如特定移动设备的文件夹中。) 以下示例演示如何在配置文件中设置 提供程序 属性:<system.web> <browserCaps provider="ClassLibrary2.CustomProvider, ClassLibrary2, Version=1.0.0.0, Culture=neutral" /> </system.web>
注册新浏览器功能定义的另一种方法是使用代码,如以下示例所示:
void Application_Start(object sender, EventArgs e) { HttpCapabilitiesBase.BrowserCapabilitiesProvider = new ClassLibrary2.CustomProvider(); // ... }
此代码必须在文件的 Application_Start 事件中
Global.asax
运行。 在执行应用程序中的任何代码之前,必须对 BrowserCapabilitiesProvider 类进行任何更改,以确保缓存对于解析的 HttpCapabilitiesBase 对象保持有效状态。
缓存 HttpBrowserCapabilities 对象
前面的示例有一个问题,即每次调用自定义提供程序时,代码都会运行以获取 HttpBrowserCapabilities 对象。 在每个请求期间,可能会多次发生此情况。 在示例中,提供程序的代码没有执行太多操作。 但是,如果自定义提供程序中的代码执行大量工作以获取 HttpBrowserCapabilities 对象,则可能会影响性能。 若要防止这种情况发生,可以缓存 HttpBrowserCapabilities 对象。 执行以下步骤:
创建派生自 HttpCapabilitiesProvider 的类,如以下示例所示:
public class CustomProvider : HttpCapabilitiesProvider { public override HttpBrowserCapabilities GetBrowserCapabilities(HttpRequest request) { string cacheKey = BuildCacheKey(); int cacheTime = GetCacheTime(); HttpBrowserCapabilities browserCaps = HttpContext.Current.Cache[cacheKey] as HttpBrowserCapabilities; if (browserCaps == null) { HttpBrowserCapabilities browserCaps = new HttpBrowserCapabilities(); Hashtable values = new Hashtable(180, StringComparer.OrdinalIgnoreCase); values[String.Empty] = request.UserAgent; values["browser"] = "MyCustomBrowser"; browserCaps.Capabilities = values; HttpContext.Current.Cache.Insert(cacheKey, browserCaps, null, DateTime.MaxValue, TimeSpan.FromSeconds(cacheTime)); } return browserCaps; } }
在示例中,代码通过调用自定义 BuildCacheKey 方法生成缓存密钥,并通过调用自定义 GetCacheTime 方法获取缓存时间长度。 然后,该代码将解析的 HttpBrowserCapabilities 对象添加到缓存中。 可以从缓存中检索 对象,并在使用自定义提供程序的后续请求上重复使用。
如前面的过程中所述,将提供程序注册到应用程序。
扩展 ASP.NET 浏览器功能功能
上一部分介绍了如何在 ASP.NET 4 中创建新的 HttpBrowserCapabilities 对象。 还可以通过将新的浏览器功能定义添加到 ASP.NET 中已有的浏览器功能定义来扩展 ASP.NET 浏览器功能。 无需使用 XML 浏览器定义即可执行此操作。 以下过程演示了操作方法。
创建一个从 HttpCapabilitiesEvaluator 派生并重写 GetBrowserCapabilities 方法的类,如以下示例所示:
public class CustomProvider : HttpCapabilitiesEvaluator { public override HttpBrowserCapabilities GetBrowserCapabilities(HttpRequest request) { HttpBrowserCapabilities browserCaps = base.GetHttpBrowserCapabilities(request); if (browserCaps.Browser == "Unknown") { browserCaps = MyBrowserCapabilitiesEvaulator(request); } return browserCaps; } }
此代码首先使用 ASP.NET 浏览器功能来尝试识别浏览器。 但是,如果没有根据请求中定义的信息来标识浏览器, (也就是说,如果 HttpBrowserCapabilities 对象的 Browser 属性是字符串“Unknown”) ,则代码将调用自定义提供程序 (MyBrowserCapabilitiesEvaluator) 来标识浏览器。
如前面的示例中所述,将提供程序注册到应用程序。
通过向现有功能定义添加新功能来扩展浏览器功能
除了创建自定义浏览器定义提供程序和动态创建新的浏览器定义外,还可以使用其他功能扩展现有浏览器定义。 这允许你使用一个接近所需内容但仅缺少一些功能的定义。 为此,请执行下列步骤。
创建一个从 HttpCapabilitiesEvaluator 派生并重写 GetBrowserCapabilities 方法的类,如以下示例所示:
public class CustomProvider : HttpCapabilitiesEvaluator { public override HttpBrowserCapabilities GetBrowserCapabilities(HttpRequest request) { HttpBrowserCapabilities browserCaps = base.GetHttpBrowserCapabilities(request); if (browserCaps.Browser == "Unknown") { browserCaps = MyBrowserCapabilitiesEvaulator(request); } return browserCaps; } }
示例代码扩展现有的 ASP.NET HttpCapabilitiesEvaluator 类,并使用以下代码获取与当前请求定义匹配的 HttpBrowserCapabilities 对象:
HttpBrowserCapabilities browserCaps = base.GetHttpBrowserCapabilities(request);
然后,代码可以添加或修改此浏览器的功能。 可通过两种方式指定新的浏览器功能:
将键/值对添加到由 HttpCapabilitiesBase 对象的 Capabilities 属性公开的 IDictionary 对象。 在前面的示例中,代码添加了一个名为 MultiTouch 的功能,其值为 true。
设置 HttpCapabilitiesBase 对象的现有属性。 在前面的示例中,代码将 Frames 属性设置为 true。 此属性只是由 Capabilities 属性公开的 IDictionary 对象的访问器。
注意
注意 此模型适用于 HttpBrowserCapabilities 的任何属性,包括控件适配器。
如前面的过程中所述,将提供程序注册到应用程序。
ASP.NET 4 中的路由
ASP.NET 4 添加了对将路由与 Web Forms 结合使用的内置支持。 通过路由,可以将应用程序配置为接受不映射到物理文件的请求 URL。 相反,可以使用路由来定义对用户有意义的 URL,并有助于搜索引擎优化 (SEO) 应用程序。 例如,在现有应用程序中显示产品类别的页面的 URL 可能如以下示例所示:
http://website/products.aspx?categoryid=12
通过使用路由,可以将应用程序配置为接受以下 URL 来呈现相同的信息:
http://website/products/software
从 ASP.NET 3.5 SP1 开始提供路由。 (有关如何在 ASP.NET 3.5 SP1 中使用路由的示例,请参阅但是,使用 Phil Haack 博客上的 WebForms 进行路由 ) 但是,ASP.NET 4 包含一些使路由更易于使用的功能,包括以下内容:
- PageRouteHandler 类,它是定义路由时使用的简单 HTTP 处理程序。 类将数据传递到请求路由到的页面。
- 新属性 HttpRequest.RequestContext 和 Page.RouteData (这是 httpRequest.RequestContext.RouteData 对象的代理) 。 通过这些属性,可以更轻松地访问从路由传递的信息。
- 以下新的表达式生成器,在 System.Web.Compilation.RouteUrlExpressionBuilder 和 System.Web.Compilation.RouteValueExpressionBuilder 中定义:
- RouteUrl,提供了一种创建与 ASP.NET 服务器控件中的路由 URL 相对应的 URL 的简单方法。
- RouteValue,它提供了一种从 RouteContext 对象中提取信息的简单方法。
- RouteParameter 类,可以更轻松地将 RouteContext 对象中包含的数据传递给数据源控件的查询, (类似于 FormParameter) 。
Web Forms页面的路由
以下示例演示如何使用 Route 类的新 MapPageRoute 方法定义Web Forms路由:
public class Global : System.Web.HttpApplication
{
void Application_Start(object sender, EventArgs e)
{
RouteTable.Routes.MapPageRoute("SearchRoute",
"search/{searchterm}", "~/search.aspx");
RouteTable.Routes.MapPageRoute("UserRoute",
"users/{username}", "~/users.aspx");
}
}
ASP.NET 4 引入了 MapPageRoute 方法。 以下示例等效于上一示例中所示的 SearchRoute 定义,但使用 PageRouteHandler 类。
RouteTable.Routes.Add("SearchRoute", new Route("search/{searchterm}",
new PageRouteHandler("~/search.aspx")));
示例中的代码将路由映射到第一个路由中的物理页 (映射到 ~/search.aspx
) 。 第一个路由定义还指定应从 URL 中提取名为 searchterm 的参数并将其传递给页面。
MapPageRoute 方法支持以下方法重载:
- MapPageRoute (string routeName、string routeUrl、string physicalFile、bool checkPhysicalUrlAccess)
- MapPageRoute (string routeName、string routeUrl、string physicalFile、bool checkPhysicalUrlAccess、RouteValueDictionary 默认值)
- MapPageRoute (string routeName、string routeUrl、string physicalFile、bool checkPhysicalUrlAccess、RouteValueDictionary 默认值、RouteValueDictionary 约束)
checkPhysicalUrlAccess 参数指定路由是否应检查要路由到 (的物理页面的安全权限,在本例中,search.aspx) ,以及在本例中 (传入 URL 的权限,search/{searchterm}) 。 如果 checkPhysicalUrlAccess 的值为 false,则仅检查传入 URL 的权限。 这些权限是使用如下设置在 Web.config
文件中定义的:
<configuration>
<location path="search.aspx">
<system.web>
<authorization>
<allow roles="admin"/>
<deny users="*"/>
</authorization>
</system.web>
</location>
<location path="search">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
</configuration>
在示例配置中,除具有管理员角色的用户外,所有用户都拒绝访问物理页面 search.aspx
。 如果 checkPhysicalUrlAccess 参数设置为 true (这是其默认值) ,则仅允许管理员用户访问 URL /search/{searchterm},因为物理页面 search.aspx 仅限于该角色的用户。 如果 checkPhysicalUrlAccess 设置为 false ,并且网站已如上一示例中所示进行配置,则允许所有经过身份验证的用户访问 URL /search/{searchterm}。
在Web Forms页中读取路由信息
在Web Forms物理页的代码中,可以使用两个新属性(HttpRequest.RequestContext 和 Page.RouteData)访问路由从 URL (提取的信息,或者另一个对象已添加到 RouteData 对象) 的其他信息。 (Page.RouteData 包装 HttpRequest.RequestContext.RouteData.) 以下示例演示如何使用 Page.RouteData。
protected void Page_Load(object sender, EventArgs e)
{
string searchterm = Page.RouteData.Values["searchterm"] as string;
label1.Text = searchterm;
}
代码提取为 searchterm 参数传递的值,如前面的示例路由中定义的那样。 请考虑以下请求 URL:
http://localhost/search/scott/
发出此请求时,“scott”一词将在页面中呈现 search.aspx
。
访问标记中的路由信息
上一部分所述的 方法演示如何在Web Forms页中的代码中获取路由数据。 还可以在标记中使用表达式,使你能够访问相同的信息。 表达式生成器是使用声明性代码的一种强大而简洁的方式。 (有关详细信息,请参阅 Phil Haack 博客上的条目 “使用自定义表达式生成器表达自己 ”。)
ASP.NET 4 包括两个新的表达式生成器,用于Web Forms路由。 以下示例演示如何使用它们。
<asp:HyperLink ID="HyperLink1" runat="server"
NavigateUrl="<%$RouteUrl:SearchTerm=scott%>">Search for Scott</asp:HyperLink>
在此示例中, RouteUrl 表达式用于定义基于路由参数的 URL。 这样就不必将完整的 URL 硬编码到标记中,并允许您在以后更改 URL 结构,而无需对此链接进行任何更改。
根据前面定义的路由,此标记生成以下 URL:
http://localhost/search/scott
ASP.NET 自动计算出正确的路由 (,它会根据输入参数生成正确的 URL) 。 还可以在表达式中包含路由名称,以便指定要使用的路由。
以下示例演示如何使用 RouteValue 表达式。
<asp:Label ID="Label1" runat="server" Text="<%$RouteValue:SearchTerm%>" />
当包含此控件的页面运行时,标签中会显示值“scott”。
RouteValue 表达式使在标记中使用路由数据变得简单,并且无需在标记中使用更复杂的 Page.RouteData[“x”] 语法。
将路由数据用于数据源控制参数
RouteParameter 类允许将路由数据指定为数据源控件中查询的参数值。 它 的工作方式与 类非常类似 ,如以下示例所示:
<asp:sqldatasource id="SqlDataSource1" runat="server"
connectionstring="<%$ ConnectionStrings:MyNorthwind %>"
selectcommand="SELECT CompanyName,ShipperID FROM Shippers where
CompanyName=@companyname"
<selectparameters>
<asp:routeparameter name="companyname" RouteKey="searchterm" />
</selectparameters>
</asp:sqldatasource>
在这种情况下,路由参数 searchterm 的值将用于 @companynameSelect 语句中的 参数。
设置客户端 ID
新的 ClientIDMode 属性解决了 ASP.NET 中长期存在的问题,即控件如何为其呈现的元素创建 id 属性。 如果应用程序包含引用这些元素的客户端脚本,则了解呈现元素的 id 属性非常重要。
HTML 中为 Web 服务器控件呈现的 id 属性基于控件的 ClientID 属性生成。 在 ASP.NET 4 之前,用于从 ClientID 属性生成 id 属性的算法是连接命名容器 ((如果有任何与 ID) ),在重复控件 (的情况下,如在数据控件) 中一样,添加前缀和顺序数字。 虽然这始终保证页面中控件的 ID 是唯一的,但算法导致控件 ID 不可预测,因此很难在客户端脚本中引用。
通过新的 ClientIDMode 属性,可以更精确地指定如何为控件生成客户端 ID。 可以为任何控件(包括页面)设置 ClientIDMode 属性。 可能的设置如下:
- AutoID – 这等效于生成早期版本的 ASP.NET 中使用的 ClientID 属性值的算法。
- 静态 – 这指定 ClientID 值将与 ID 相同,而不连接父命名容器的 ID。 这在 Web 用户控件中很有用。 由于 Web 用户控件可以位于不同的页面和不同的容器控件中,因此很难为使用 AutoID 算法的控件编写客户端脚本,因为你无法预测 ID 值。
- 可预测 - 此选项主要用于使用重复模板的数据控件。 它连接控件命名容器的 ID 属性,但生成的 ClientID 值不包含类似于“ctlxxx”的字符串。 此设置与 控件的 ClientIDRowSuffix 属性结合使用。 将 ClientIDRowSuffix 属性设置为数据字段的名称,该字段的值将用作生成的 ClientID 值的后缀。 通常,将使用数据记录的主键作为 ClientIDRowSuffix 值。
- 继承 – 此设置是控件的默认行为;它指定控件的 ID 生成与其父级相同。
可以在页面级别设置 ClientIDMode 属性。 这将定义当前页中所有控件的默认 ClientIDMode 值。
页面级别的默认 ClientIDMode 值为 AutoID,控件级别的默认 ClientIDMode 值为 Inherit。 因此,如果未在代码中的任何位置设置此属性,则所有控件都将默认为 AutoID 算法。
在 @ Page 指令中设置页面级值,如以下示例所示:
<%@ Page Language="C#" AutoEventWireup="true"
CodeFile="Default.aspx.cs"
Inherits="_Default"
ClientIDMode="Predictable" %>
还可以在配置文件中设置 ClientIDMode 值,无论是在计算机 (计算机) 级别,还是在应用程序级别。 这将为应用程序的所有页中的所有控件定义默认的 ClientIDMode 设置。 如果在计算机级别设置值,它将为该计算机上的所有网站定义默认 的 ClientIDMode 设置。 以下示例演示配置文件中的 ClientIDMode 设置:
<system.web>
<pages clientIDMode="Predictable"></pages>
</system.web>
如前所述, ClientID 属性的值派生自控件父级的命名容器。 在某些情况下(例如,使用母版页时),控件最终可能会得到 ID,如以下呈现的 HTML 中的 ID:
<div id="ctl00_ContentPlaceHolder1_ParentPanel">
<div id="ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1">
<input name="ctl00$ContentPlaceHolder1$ParentPanel$NamingPanel1$TextBox1"
type="text" value="Hello!"
id="ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1_TextBox1" />
</div>
尽管标记中显示的 输入 元素 (来自 TextBox 控件) 只是页面深处的两个命名容器, (嵌套的 ContentPlaceholder 控件) ,由于母版页的处理方式,最终结果是控件 ID 如下所示:
ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1_TextBox1
此 ID 保证在页面中是唯一的,但对于大多数目的来说,该 ID 不必要地很长。 假设你想要减少呈现的 ID 的长度,并更好地控制 ID 的生成方式。 (例如,要消除“ctlxxx”prefixes.) 最简单的方法是设置 ClientIDMode 属性,如以下示例所示:
<tc:NamingPanel runat="server" ID="ParentPanel" ClientIDMode="Static">
<tc:NamingPanel runat="server" ID="NamingPanel1" ClientIDMode="Predictable">
<asp:TextBox ID="TextBox1" runat="server" Text="Hello!"></asp:TextBox>
</tc:NamingPanel>
</tc:NamingPanel>
在此示例中,对于最外层的 NamingPanel 元素,ClientIDMode 属性设置为 Static,对于内部 NamingControl 元素,设置为 Predictable。 这些设置会导致以下标记 (页面的其余部分,并且假定母版页与前面的示例) 相同:
<div id="ParentPanel">
<div id="ParentPanel_NamingPanel1">
<input name="ctl00$ContentPlaceHolder1$ParentPanel$NamingPanel1$TextBox1"
type="text" value="Hello!" id="ParentPanel_NamingPanel1_TextBox1" />
</div>
Static 设置的作用是重置最外层 NamingPanel 元素内的任何控件的命名层次结构,以及从生成的 ID 中删除 ContentPlaceHolder 和 MasterPage ID。 (呈现的元素 的名称 属性不受影响,因此会保留事件、视图状态等的正常 ASP.NET 功能。) 重置命名层次结构的副作用是,即使将 NamingPanel 元素的标记移动到其他 ContentPlaceholder 控件,呈现的客户端 ID 也保持不变。
注意
注意 由你来决定确保呈现的控件 ID 是唯一的。 否则,它可能会破坏需要单个 HTML 元素的唯一 ID 的任何功能,例如 client document.getElementById 函数。
在 Data-Bound 控件中创建可预测客户端 ID
旧算法为数据绑定列表控件中的控件生成的 ClientID 值可能很长,并且不可预测。 ClientIDMode 功能可帮助你更好地控制这些 ID 的生成方式。
以下示例中的标记包括 一个 ListView 控件:
<asp:ListView ID="ListView1" runat="server" DataSourceID="SqlDataSource1"
OnSelectedIndexChanged="ListView1_SelectedIndexChanged"
ClientIDMode="Predictable"
RowClientIDRowSuffix="ProductID">
</asp:ListView>
在前面的示例中, ClientIDMode 和 RowClientIDRowSuffix 属性在标记中设置。 ClientIDRowSuffix 属性只能在数据绑定控件中使用,其行为因所使用的控件而异。 区别如下:
GridView 控件 — 可以指定数据源中一列或多列的名称,这些列在运行时合并以创建客户端 ID。 例如,如果将 RowClientIDRowSuffix 设置为“ProductName, ProductId”,则呈现的元素的控件 ID 将采用如下格式:
rootPanel_GridView1_ProductNameLabel_Chai_1
ListView 控件 — 可以在数据源中指定追加到客户端 ID 的单个列。 例如,如果将 ClientIDRowSuffix 设置为“ProductName”,则呈现的控件 ID 将采用如下所示的格式:
rootPanel_ListView1_ProductNameLabel_1
在这种情况下,尾随 1 派生自当前数据项的产品 ID。
Repeater 控件 — 此控件不支持 ClientIDRowSuffix 属性。 在 Repeater 控件中,使用当前行的索引。 将 ClientIDMode=“Predictable”与 Repeater 控件一起使用时,将生成具有以下格式的客户端 ID:
Repeater1_ProductNameLabel_0
尾随 0 是当前行的索引。
FormView 和 DetailsView 控件不显示多行,因此它们不支持 ClientIDRowSuffix 属性。
在数据控件中保留行选择
GridView 和 ListView 控件可让用户选择行。 在早期版本的 ASP.NET 中,选择基于页面上的行索引。 例如,如果选择第 1 页上的第三项,然后移动到第 2 页,则会选择该页上的第三项。
暂留选择最初仅在 .NET Framework 3.5 SP1 中的动态数据项目中受支持。 启用此功能后,当前所选项基于该项的数据键。 这意味着,如果选择第 1 页上的第三行并移动到第 2 页,则不会在第 2 页上选择任何内容。 当移回第 1 页时,仍会选择第三行。 现在,通过使用 EnablePersistedSelection 属性,所有项目中的 GridView 和 ListView 控件都支持持久选择,如以下示例所示:
<asp:GridView id="GridView2" runat="server" EnablePersistedSelection="true">
</asp:GridView>
ASP.NET 图表控件
ASP.NET 图表控件扩展.NET Framework中的数据可视化产品/服务。 使用 图表 控件,可以创建 ASP.NET 页面,这些页面具有直观且具有视觉吸引力的图表,用于复杂的统计或财务分析。 ASP.NET 图表控件作为 .NET Framework 版本 3.5 SP1 版本的加载项引入,是 .NET Framework 4 版本的一部分。
控件包括以下功能:
- 35 种不同的图表类型。
- 无限数量的图表区域、标题、图例和批注。
- 所有图表元素的各种外观设置。
- 对大多数图表类型的三维支持。
- 可自动适应数据点的智能数据标签。
- 条带线、刻度分隔符和对数缩放。
- 包含 50 多个用于数据分析和转换的财务和统计公式。
- 简单绑定和操作图表数据。
- 支持常见数据格式,例如日期、时间和货币。
- 支持交互和事件驱动的自定义,包括使用 Ajax 的客户端单击事件。
- 状态管理。
- 二进制流。
下图显示了 ASP.NET 图表控件生成的财务图表示例。
图 2:ASP.NET 图表控件示例
有关如何使用 ASP.NET Chart 控件的更多示例,请在 MSDN 网站上的 Microsoft Chart Controls 示例环境 页上下载示例代码。 可以在 图表控件论坛上找到更多社区内容示例。
将图表控件添加到 ASP.NET 页
以下示例演示如何使用标记将 Chart 控件添加到 ASP.NET 页。 在此示例中, Chart 控件为静态数据点生成柱形图。
<asp:Chart ID="Chart1" runat="server">
<Series>
<asp:Series Name="Series1" ChartType="Column">
<Points>
<asp:DataPoint AxisLabel="Product A" YValues="345"/>
<asp:DataPoint AxisLabel="Product B" YValues="456"/>
<asp:DataPoint AxisLabel="Product C" YValues="125"/>
<asp:DataPoint AxisLabel="Product D" YValues="957"/> &
lt;/Points>
</asp:Series>
</Series>
<ChartAreas>
<asp:ChartArea Name="ChartArea1">
<AxisY IsLogarithmic="True" />
</asp:ChartArea>
</ChartAreas>
<Legends>
<asp:Legend Name="Legend1" Title="Product Sales" />
</Legends>
</asp:Chart>
使用三维图表
Chart 控件包含 ChartAreas 集合,该集合可以包含定义图表区域特征的 ChartArea 对象。 例如,若要对图表区域使用三维,请使用 Area3DStyle 属性,如以下示例所示:
<asp:ChartArea Name="ChartArea1">
<area3dstyle
Rotation="10"
Perspective="10"
Enable3D="True"
Inclination="15"
IsRightAngleAxes="False"
WallWidth="0"
IsClustered="False" />
<%-- Additional markup here --%>
</asp:ChartArea>
下图显示了一个三维图表,其中包含 条形 图类型的四个系列。
图 3:三维条形图
使用刻度分隔符和对数刻度
刻度分隔符和对数刻度是增加图表复杂性的另外两种方法。 这些功能特定于图表区中的每个轴。 例如,若要在图表区的主 Y 轴上使用这些功能,请在 ChartArea 对象中使用 AxisY.IsLogarithmic 和 ScaleBreakStyle 属性。 以下代码片段演示如何在主 Y 轴上使用刻度分隔线。
<asp:ChartArea Name="ChartArea1">
<axisy>
<ScaleBreakStyle
BreakLineStyle="Wave"
CollapsibleSpaceThreshold="40"
Enabled="True" />
</axisy>
<%-- Additional markup here --%>
</asp:ChartArea>
下图显示了启用了刻度分隔符的 Y 轴。
图 4:刻度分隔符
使用 QueryExtender 控件筛选数据
对于创建数据驱动网页的开发人员来说,一个非常常见的任务是筛选数据。 这传统上是通过在数据源控件中生成 Where 子句来执行的。 此方法可能很复杂,在某些情况下, Where 语法不允许利用基础数据库的完整功能。
为了简化筛选,ASP.NET 4 中添加了一个新的 QueryExtender 控件。 可以将此控件添加到 EntityDataSource 或 LinqDataSource 控件,以便筛选这些控件返回的数据。 由于 QueryExtender 控件依赖于 LINQ,因此,在将数据发送到页面之前,筛选器将应用于数据库服务器,这会导致非常高效的操作。
QueryExtender 控件支持各种筛选器选项。 以下部分介绍这些选项并提供如何使用它们的示例。
搜索
对于搜索选项, QueryExtender 控件在指定字段中执行搜索。 在以下示例中,控件使用在 TextBoxSearch 控件中输入的文本,并在从 LinqDataSource 控件返回的数据中的 和 Supplier.CompanyName
列中搜索其内容ProductName
。
<asp:LinqDataSource ID="dataSource" runat="server"> TableName="Products">
</asp:LinqDataSource>
<asp:QueryExtender TargetControlID="dataSource" runat="server">
<asp:SearchExpression DataFields="ProductName, Supplier.CompanyName"
SearchType="StartsWith">
<asp:ControlParameter ControlID="TextBoxSearch" />
</asp:SearchExpression>
</asp:QueryExtender>
范围
range 选项类似于搜索选项,但指定一对值来定义范围。 在以下示例中,QueryExtender 控件在从 LinqDataSource 控件返回的数据中搜索UnitPrice
列。 从页面上的 TextBoxFrom 和 TextBoxTo 控件读取该区域。
<asp:LinqDataSource ID="dataSource" runat="server"> TableName="Products">
</asp:LinqDataSource>
<asp:QueryExtender TargetControlID="dataSource" runat="server">
<asp:RangeExpression DataField="UnitPrice" MinType="Inclusive"
MaxType="Inclusive">
<asp:ControlParameter ControlID="TextBoxFrom" />
<asp:ControlParameter ControlID="TexBoxTo" />
</asp:RangeExpression>
</asp:QueryExtender>
PropertyExpression
使用属性表达式选项可以定义与属性值的比较。 如果表达式的计算结果为 true,则返回正在检查的数据。 在以下示例中, QueryExtender 控件通过将 列中的数据 Discontinued
与页面上 CheckBoxDisconued 控件中的值进行比较来筛选数据。
<asp:LinqDataSource ID="dataSource" runat="server" TableName="Products">
</asp:LinqDataSource>
<asp:QueryExtender TargetControlID="dataSource" runat="server">
<asp:PropertyExpression>
<asp:ControlParameter ControlID="CheckBoxDiscontinued" Name="Discontinued" />
</asp:PropertyExpression>
</asp:QueryExtender>
CustomExpression
最后,可以指定要与 QueryExtender 控件一起使用的自定义表达式。 此选项允许你在定义自定义筛选器逻辑的页面中调用函数。 以下示例演示如何在 QueryExtender 控件中以声明方式指定自定义表达式。
<asp:LinqDataSource ID="dataSource" runat="server" TableName="Products">
</asp:LinqDataSource>
<asp:QueryExtender TargetControlID="dataSource" runat="server">
<asp:CustomExpression OnQuerying="FilterProducts" />
</asp:QueryExtender>
下面的示例演示由 QueryExtender 控件调用的自定义函数。 在这种情况下,代码使用 LINQ 查询来筛选数据,而不是使用包含 Where 子句的数据库查询。
protected void FilterProducts(object sender, CustomExpressionEventArgs e)
{
e.Query = from p in e.Query.Cast()
where p.UnitPrice >= 10
select p;
}
这些示例一次只显示 QueryExtender 控件中使用的一个表达式。 但是,可以在 QueryExtender 控件中包含多个表达式。
Html 编码的代码表达式
一些 ASP.NET 网站 (特别是 ASP.NET MVC) 严重依赖使用 <%
= expression %>
语法 (通常称为“代码块”的语法,) 将一些文本写入响应。 使用代码表达式时,很容易忘记对文本进行 HTML 编码,如果文本来自用户输入,它可能会使页面对 XSS (跨站点脚本) 攻击保持打开状态。
ASP.NET 4 引入了以下代码表达式的新语法:
<%: expression %>
写入响应时,此语法默认使用 HTML 编码。 此新表达式有效地转换为以下内容:
<%= HttpUtility.HtmlEncode(expression) %>
例如, <%: Request[“UserInput”] %> 对 Request[“UserInput”] 的值执行 HTML 编码。
此功能的目标是能够将旧语法的所有实例替换为新语法,这样就不必在每一步都决定要使用哪个实例。 但是,在某些情况下,要输出的文本应为 HTML 或已编码,在这种情况下,这可能会导致双重编码。
对于这些情况,ASP.NET 4 引入了新的接口 IHtmlString,以及具体的实现 HtmlString。 通过这些类型的实例,可以指示返回值已正确编码 (或以其他方式检查) 是否显示为 HTML,因此不应再次对值进行 HTML 编码。 例如,不应将以下内容 (且不) HTML 编码:
<%: new HtmlString("<strong>HTML that is not encoded</strong>") %>
ASP.NET MVC 2 帮助程序方法已更新为使用此新语法,因此它们不会进行双重编码,而仅在运行 ASP.NET 4 时进行。 使用 ASP.NET 3.5 SP1 运行应用程序时,此新语法不起作用。
请记住,这并不能保证免受 XSS 攻击。 例如,使用不在引号中的属性值的 HTML 可以包含仍易受影响的用户输入。 请注意,ASP.NET 控件和 ASP.NET MVC 帮助器的输出始终在引号中包含属性值,这是建议的方法。
同样,此语法不执行 JavaScript 编码,例如,基于用户输入创建 JavaScript 字符串时。
项目模板更改
在早期版本的 ASP.NET 中,使用 Visual Studio 创建新的网站项目或 Web 应用程序项目时,生成的项目仅包含 Default.aspx 页、App_Data
默认Web.config
文件和 文件夹,如下图所示:
Visual Studio 还支持空网站项目类型,它根本不包含任何文件,如下图所示:
因此,对于初学者来说,关于如何生成生产 Web 应用程序的指南很少。 因此,ASP.NET 4 引入了三个新模板,一个用于空的 Web 应用程序项目,一个用于 Web 应用程序和网站项目。
空 Web 应用程序模板
顾名思义,空 Web 应用程序模板是一个删除的 Web 应用程序项目。 从“Visual Studio 新建项目”对话框中选择此项目模板,如下图所示:
创建空 ASP.NET Web 应用程序时,Visual Studio 会创建以下文件夹布局:
这类似于早期版本的 ASP.NET 的空网站布局,但有一个例外。 在 Visual Studio 2010 中,空 Web 应用程序和空网站项目包含以下最小 Web.config
文件,其中包含 Visual Studio 用于标识项目目标框架的信息:
如果没有此 targetFramework 属性,Visual Studio 默认以 .NET Framework 2.0 为目标,以便在打开较旧的应用程序时保持兼容性。
Web 应用程序和网站项目模板
Visual Studio 2010 附带的其他两个新项目模板包含重大更改。 下图显示了在创建新的 Web 应用程序项目时创建的项目布局。 (网站项目的布局几乎完全相同。)
该项目包含许多未在早期版本中创建的文件。 此外,新的 Web 应用程序项目配置了基本的成员身份功能,使你能够快速开始保护对新应用程序的访问。 由于包含此内容, Web.config
新项目的文件包含用于配置成员资格、角色和配置文件的条目。 以下示例显示了 Web.config
新 Web 应用程序项目的 文件。 (在这种情况下, 将禁用 roleManager 。)
该项目还包含目录中的第二 Web.config
个文件 Account
。 第二个配置文件为非登录用户提供了一种保护对 ChangePassword.aspx 页面的访问的方法。 以下示例显示第二 Web.config
个文件的内容。
默认情况下在新项目模板中创建的页面包含的内容也比以前版本多。 项目包含默认母版页和 CSS 文件,默认页面 (Default.aspx) 配置为默认使用母版页。 结果是首次运行 Web 应用程序或网站时,默认 (主页) 页已正常运行。 事实上,它类似于启动新的 MVC 应用程序时看到的默认页面。
对项目模板进行这些更改的目的是提供有关如何开始生成新 Web 应用程序的指南。 模板中的页面具有语义正确的严格 XHTML 1.0 兼容标记和使用 CSS 指定的布局,表示生成 ASP.NET 4 Web 应用程序的最佳做法。 默认页面还具有可轻松自定义的双列布局。
例如,假设对于新的 Web 应用程序,你想要更改某些颜色,并插入公司徽标来代替“我的 ASP.NET 应用程序”徽标。 为此,请在 下 Content
创建一个新目录来存储徽标图像:
若要将图像添加到页面,然后打开Site.Master
文件,查找定义 My ASP.NET Application 文本的位置,并将其替换为其 src 属性设置为新徽标图像的图像元素,如以下示例所示:
然后,可以转到 Site.css 文件并修改 CSS 类定义,以更改页面的背景色以及页眉的背景色。
这些更改的结果是,你可以毫不费力地显示自定义主页:
CSS 改进
ASP.NET 4 的主要工作领域之一是帮助呈现符合最新 HTML 标准的 HTML。 这包括更改 ASP.NET Web 服务器控件使用 CSS 样式的方式。
呈现的兼容性设置
默认情况下,当 Web 应用程序或网站面向.NET Framework 4 时,pages 元素的 controlRenderingCompatibilityVersion 属性设置为“4.0”。 此元素在计算机级 Web.config
文件中定义,默认情况下适用于所有 ASP.NET 4 个应用程序:
<system.web>
<pages controlRenderingCompatibilityVersion="3.5|4.0"/>
</system.web>
controlRenderingCompatibility 的值是一个字符串,它允许将来的版本中潜在的新版本定义。 在当前版本中,此属性支持以下值:
- "3.5". 此设置指示旧版呈现和标记。 控件呈现的标记是 100% 向后兼容的,并且采用 xhtmlConformance 属性的设置。
- "4.0". 如果 属性具有此设置,ASP.NET Web 服务器控件执行以下操作:
- xhtmlConformance 属性始终被视为“Strict”。 因此,控件呈现 XHTML 1.0 Strict 标记。
- 禁用非输入控件不再呈现无效样式。
- 隐藏字段周围的 div 元素现在已设置样式,因此它们不会干扰用户创建的 CSS 规则。
- 菜单控件呈现语义正确且符合辅助功能准则的标记。
- 验证控件不呈现内联样式。
- 以前呈现 border=“0” 的控件 (派生自 ASP.NET Table 控件的控件,ASP.NET Image 控件) 不再呈现此属性。
禁用控件
在 ASP.NET 3.5 SP1 及更早版本中,框架在 HTML 标记中为 Enabled 属性设置为 false 的任何控件呈现 disabled 属性。 但是,根据 HTML 4.01 规范,只有 输入 元素才应具有此属性。
在 ASP.NET 4 中,可以将 controlRenderingCompatibilityVersion 属性设置为“3.5”,如以下示例所示:
<system.web>
<pages controlRenderingCompatibilityVersion="3.5"/>
</system.web>
可以按如下所示为 Label 控件创建标记,这会禁用该控件:
<asp:Label id="Label" runat="server" Text="Test" Enabled="false">
Label 控件将呈现以下 HTML:
<span id="Label1" disabled="disabled">Test</span>
在 ASP.NET 4 中,可以将 controlRenderingCompatibilityVersion 设置为“4.0”。 在这种情况下,当控件的 Enabled 属性设置为 false 时,只有呈现输入元素的控件才会呈现禁用的属性。 不呈现 HTML 输入 元素的控件呈现引用 CSS 类的 类 属性,可用于定义控件的禁用外观。 例如,前面示例中所示的 Label 控件将生成以下标记:
<span id="Span1" class="aspnetdisabled">Test</span>
为此控件指定的类的默认值为“aspNetDisabled”。 但是,可以通过设置 WebControl 类的静态 DisabledCssClass 静态属性来更改此默认值。 对于控件开发人员,还可以使用 SupportsDisabledAttribute 属性定义用于特定控件的行为。
隐藏隐藏字段周围的 div 元素
ASP.NET 2.0 及更高版本呈现系统特定的隐藏字段 (,例如用于在 div 元素内存储视图状态信息的隐藏元素) ,以符合 XHTML 标准。 但是,当 CSS 规则影响页面上的 div 元素时,这可能会导致问题。 例如,它可能导致在隐藏 的 div 元素周围的页面中出现一条像素线。 在 ASP.NET 4 中,包含由 ASP.NET 生成的隐藏字段的 div 元素添加 CSS 类引用,如以下示例所示:
<div class="aspNetHidden">...</div>
然后,可以定义一个 CSS 类,该类仅适用于 ASP.NET 生成的 隐藏 元素,如以下示例所示:
<style type="text/css">
DIV# aspNetHidden {border:0;}
</style>
呈现模板化控件的外部表
默认情况下,支持模板的以下 ASP.NET Web 服务器控件会自动包装在用于应用内联样式的外部表中:
- FormView
- 登录
- PasswordRecovery
- ChangePassword
- 向导
- CreateUserWizard
这些控件中添加了一个名为 RenderOuterTable 的新属性,该属性允许从标记中删除外部表。 例如,请考虑以下 FormView 控件的示例:
<asp:FormView ID="FormView1" runat="server">
<ItemTemplate>
Content
</ItemTemplate>
</asp:FormView>
此标记将以下输出呈现到页面,其中包括一个 HTML 表:
<table cellspacing="0" border="0" id="Table1" style="border-collapse:collapse;">
<tr>
<td colspan="2">
Content
</td>
</tr>
</table>
若要防止呈现表,可以设置 FormView 控件的 RenderOuterTable 属性,如以下示例所示:
<asp:FormView ID="FormView1" runat="server" RenderOuterTable="false">
上一示例呈现以下输出,不包含 table、 tr 和 td 元素:
Content
这种增强功能可以更轻松地使用 CSS 设置控件内容的样式,因为控件不会呈现任何意外的标记。
注意
注意 此更改禁用对 Visual Studio 2010 设计器中自动格式化函数的支持,因为不再有 表 元素可以托管由自动格式化选项生成的样式属性。
ListView 控件增强功能
ListView 控件在 ASP.NET 4 中更易于使用。 控件的早期版本需要指定包含具有已知 ID 的服务器控件的布局模板。 以下标记演示了如何在 ASP.NET 3.5 中使用 ListView 控件的典型示例。
<asp:ListView ID="ListView1" runat="server">
<LayoutTemplate>
<asp:PlaceHolder ID="ItemPlaceHolder" runat="server"></asp:PlaceHolder>
</LayoutTemplate>
<ItemTemplate>
<% Eval("LastName")%>
</ItemTemplate>
</asp:ListView>
在 ASP.NET 4 中, ListView 控件不需要布局模板。 可以使用以下标记替换上一示例中所示的标记:
<asp:ListView ID="ListView1" runat="server">
<ItemTemplate>
<% Eval("LastName")%>
</ItemTemplate>
</asp:ListView>
CheckBoxList 和 RadioButtonList 控件增强功能
在 ASP.NET 3.5 中,可以使用以下两个设置为 CheckBoxList 和 RadioButtonList 指定布局:
- 流。 控件呈现 span 元素以包含其内容。
- 表。 控件呈现 表 元素以包含其内容。
以下示例显示了其中每个控件的标记。
<asp:CheckBoxList ID="CheckBoxList1" runat="server" RepeatLayout="Flow">
<asp:ListItem Text="CheckBoxList" Value="cbl" />
</asp:CheckBoxList>
<asp:RadioButtonList runat="server" RepeatLayout="Table">
<asp:ListItem Text="RadioButtonList" Value="rbl" />
</asp:RadioButtonList>
默认情况下,控件呈现类似于以下内容的 HTML:
<span id="Span2"><input id="CheckBoxList1_0" type="checkbox"
name="CheckBoxList1$0" /><label for="CheckBoxList1_0">CheckBoxList</label></span>
<table id="RadioButtonList1" border="0">
<tr>
<td><input id="RadioButtonList1_0" type="radio" name="RadioButtonList1" value="rbl" /><label for="RadioButtonList1_0">RadioButtonList</label></td>
</tr>
</table>
由于这些控件包含项列表,因此为了呈现语义正确的 HTML,它们应使用 HTML 列表 (li) 元素呈现其内容。 这使使用辅助技术读取网页的用户更容易,并使控件更易于使用 CSS 设置样式。
在 ASP.NET 4 中, CheckBoxList 和 RadioButtonList 控件支持 RepeatLayout 属性的以下新值:
- OrderedList – 内容在 ol 元素中呈现为 li 元素。
- UnorderedList – 内容在 ul 元素中呈现为 li 元素。
以下示例演示如何使用这些新值。
<asp:CheckBoxList ID="CheckBoxList1" runat="server"
RepeatLayout="OrderedList">
<asp:ListItem Text="CheckBoxList" Value="cbl" />
</asp:CheckBoxList>
<asp:RadioButtonList ID="RadioButtonList1" runat="server"
RepeatLayout="UnorderedList">
<asp:ListItem Text="RadioButtonList" Value="rbl" />
</asp:RadioButtonList>
上面的标记生成以下 HTML:
<ol id="CheckBoxList1">
<li><input id="CheckBoxList1_0" type="checkbox" name="CheckBoxList1$0" value="cbl" /><label for="CheckBoxList1_0">CheckBoxList</label></li>
</ol>
<ul id="RadioButtonList1">
<li><input id="RadioButtonList1_0" type="radio" name="RadioButtonList1" value="rbl" /><label for="RadioButtonList1_0">RadioButtonList</label></li>
</ul>
注意
注意 如果将 RepeatLayout 设置为 OrderedList 或 UnorderedList,则不能再使用 RepeatDirection 属性,并且如果在标记或代码中设置了属性,则会在运行时引发异常。 属性没有值,因为这些控件的视觉布局是使用 CSS 定义的。
菜单控件改进
在 ASP.NET 4 之前, Menu 控件呈现了一系列 HTML 表。 这使得在设置内联属性之外应用 CSS 样式变得更加困难,也不符合辅助功能标准。
在 ASP.NET 4 中,控件现在使用由无序列表和列表元素组成的语义标记呈现 HTML。 以下示例显示 Menu 控件 ASP.NET 页中的标记。
<asp:Menu ID="Menu1" runat="server">
<Items> <asp:MenuItem Text="Home" Value="Home" />
<asp:MenuItem Text="About" Value="About" />
</Items>
</asp:Menu>
当页面呈现时,控件会生成以下 HTML, (为清楚起见,省略 onclick 代码) :
<div id="Menu1">
<ul>
<li><a href="#" onclick="...">Home</a></li>
<li><a href="#" onclick="...">About</a></li>
</ul>
</div>
<script type="text/javascript">
new Sys.WebForms.Menu('Menu1');
</script>
除了呈现改进之外,菜单的键盘导航还使用焦点管理进行了改进。 当 Menu 控件获得焦点时,可以使用箭头键导航元素。 菜单控件现在还附加可访问的富 Internet 应用程序 (ARIA) 角色和属性 follo,以提高辅助功能。
菜单控件的样式呈现在页面顶部的样式块中,而不是与呈现的 HTML 元素对齐。 如果要完全控制控件的样式,可以将新的 IncludeStyleBlock 属性设置为 false,在这种情况下,不会发出样式块。 使用此属性的一种方法是使用 Visual Studio 设计器中的自动格式功能来设置菜单的外观。 然后,可以运行页面,打开页面源,然后将呈现的样式块复制到外部 CSS 文件。 在 Visual Studio 中,撤消样式并将 IncludeStyleBlock 设置为 false。 结果是使用外部样式表中的样式定义菜单外观。
向导和 CreateUserWizard 控件
ASP.NET 向导 和 CreateUserWizard 控件支持用于定义它们呈现的 HTML 的模板。 (CreateUserWizard 派生自 Wizard.) 以下示例演示完全模板化 CreateUserWizard 控件的 标记:
<asp:CreateUserWizard ID="CreateUserWizard1" runat="server" ActiveStepIndex="0">
<HeaderTemplate>
</HeaderTemplate>
<SideBarTemplate>
</SideBarTemplate>
<StepNavigationTemplate>
</StepNavigationTemplate>
<StartNavigationTemplate>
</StartNavigationTemplate>
<FinishNavigationTemplate>
</FinishNavigationTemplate>
<WizardSteps>
<asp:CreateUserWizardStep ID="CreateUserWizardStep1" runat="server">
<ContentTemplate>
</ContentTemplate>
<CustomNavigationTemplate>
</CustomNavigationTemplate>
</asp:CreateUserWizardStep>
<asp:CompleteWizardStep ID="CompleteWizardStep1" runat="server">
<ContentTemplate>
</ContentTemplate>
</asp:CompleteWizardStep>
</WizardSteps>
</asp:CreateUserWizard>
控件呈现类似于以下内容的 HTML:
<table cellspacing="0" cellpadding="0" border="0" id="CreateUserWizard1" style="border-collapse:collapse;">
<tr>
<td>Header</td>
</tr>
<tr style="height:100%;">
<td>
<table cellspacing="0" cellpadding="0" border="0" style="height:100%;width:100%;border-collapse:collapse;">
<tr>
<td style="height:100%;width:100%;"></td>
</tr>
</table>
</td>
</tr>
<tr>
<td align="right"></td>
</tr>
</table>
在 ASP.NET 3.5 SP1 中,尽管可以更改模板内容,但对 向导 控件输出的控制仍然有限。 在 ASP.NET 4 中,可以创建 LayoutTemplate 模板,并使用保留名称) (插入 PlaceHolder 控件,以指定 向导控件 的呈现方式。 下面的示例对此进行了展示:
<asp:CreateUserWizard ID="CreateUserWizard1" runat="server" ActiveStepIndex="1">
<LayoutTemplate>
<asp:PlaceHolder ID="headerPlaceholder" runat="server" />
<asp:PlaceHolder ID="sideBarPlaceholder" runat="server" />
<asp:PlaceHolder id="wizardStepPlaceholder" runat="server" />
<asp:PlaceHolder id="navigationPlaceholder" runat="server" />
</LayoutTemplate>
<HeaderTemplate>
Header
</HeaderTemplate>
<WizardSteps>
<asp:CreateUserWizardStep runat="server">
<ContentTemplate>
</ContentTemplate>
</asp:CreateUserWizardStep>
<asp:CompleteWizardStep runat="server">
<ContentTemplate>
</ContentTemplate>
</asp:CreateUserWizardStep>
</WizardSteps>
</asp:CreateUserWizard>
该示例在 LayoutTemplate 元素中包含以下命名占位符:
- headerPlaceholder – 在运行时,这由 HeaderTemplate 元素的内容替换。
- sideBarPlaceholder – 在运行时,这将替换为 SideBarTemplate 元素的内容。
- wizardStepPlaceHolder – 在运行时,这将替换为 WizardStepTemplate 元素的内容。
- navigationPlaceholder – 在运行时,这将替换为已定义的任何导航模板。
示例中使用占位符的标记呈现以下 HTML (,而模板) 中没有实际定义的内容:
<span>
</span>
现在唯一不是用户定义的 HTML 是 span 元素。 (我们预计在未来版本中,甚至不会呈现 span 元素。) 现在,你可以完全控制 向导 控件生成的几乎所有内容。
ASP.NET MVC
ASP.NET MVC 作为附加框架引入,ASP.NET 2009 年 3 月 3.5 SP1。 Visual Studio 2010 包括 ASP.NET MVC 2,其中包括新的特性和功能。
区域支持
区域允许将控制器和视图分组到大型应用程序的分区中,与其他部分相对隔离。 每个区域都可以作为单独的 ASP.NET MVC 项目实现,然后由main应用程序引用。 这有助于在生成大型应用程序时管理复杂性,并使多个团队更轻松地在单个应用程序上协同工作。
Data-Annotation 属性验证支持
DataAnnotations 属性允许使用元数据属性将验证逻辑附加到模型。 ASP.NET 3.5 SP1 的 ASP.NET Dynamic Data 中引入了 DataAnnotations 属性。 这些属性已集成到默认模型绑定器中,并提供元数据驱动的方法来验证用户输入。
模板化帮助程序
通过模板化帮助程序,你可以自动将编辑和显示模板与数据类型相关联。 例如,可以使用模板帮助程序来指定为 System.DateTime 值自动呈现日期选取器 UI 元素。 这类似于 ASP.NET 动态数据中的字段模板。
Html.EditorFor 和 Html.DisplayFor 帮助程序方法内置支持呈现标准数据类型以及具有多个属性的复杂对象。 他们还通过允许向 ViewModel 对象应用 DisplayName 和 ScaffoldColumn 等数据批注属性来自定义呈现。
通常,你希望进一步自定义 UI 帮助器的输出,并完全控制生成的内容。 Html.EditorFor 和 Html.DisplayFor 帮助程序方法使用模板化机制支持此功能,该机制允许你定义可以替代和控制呈现的输出的外部模板。 可以为类单独呈现模板。
Dynamic Data — 动态数据
2008 年年中,.NET Framework 3.5 SP1 版本中引入了动态数据。 此功能为创建数据驱动应用程序提供了许多增强功能,包括:
- 用于快速构建数据驱动网站的 RAD 体验。
- 基于数据模型中定义的约束的自动验证。
- 使用动态数据项目中的字段模板轻松更改 GridView 和 DetailsView 控件中字段生成的标记。
注意
注意 有关详细信息,请参阅 MSDN 库中的 动态数据文档 。
对于 ASP.NET 4,动态数据已得到增强,使开发人员能够更强大地快速构建数据驱动网站。
为现有项目启用动态数据
.NET Framework 3.5 SP1 中提供的动态数据功能带来了如下新功能:
- 字段模板 – 这些模板为数据绑定控件提供基于数据类型的模板。 与为每个字段使用模板字段相比,字段模板提供了一种更简单的方式来自定义数据控件的外观。
- 验证 – 动态数据允许对数据类使用属性来指定常见方案的验证,例如必填字段、范围检查、类型检查、使用正则表达式的模式匹配和自定义验证。 验证由数据控件强制实施。
但是,这些功能具有以下要求:
- 数据访问层必须基于 Entity Framework 或 LINQ to SQL。
- 这些功能支持的唯一数据源控件是 EntityDataSource 或 LinqDataSource 控件。
- 这些功能需要使用动态数据或动态数据实体模板创建的 Web 项目,才能获得支持该功能所需的所有文件。
ASP.NET 4 中动态数据支持的一个主要目标是为任何 ASP.NET 应用程序启用动态数据的新功能。 以下示例显示了可以利用现有页面中动态数据功能的控件的标记。
<asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="True"
DataKeyNames="ProductID" DataSourceID="LinqDataSource1">
</asp:GridView>
<asp:LinqDataSource ID="LinqDataSource1" runat="server"
ContextTypeName="DataClassesDataContext" EnableDelete="True" EnableInsert="True"
EnableUpdate="True" TableName="Products">
</asp:LinqDataSource>
在页面的代码中,必须添加以下代码才能为这些控件启用动态数据支持:
GridView1.EnableDynamicData(typeof(Product));
当 GridView 控件处于编辑模式时,动态数据会自动验证输入的数据的格式是否正确。 如果不是,则显示错误消息。
此功能还提供其他优势,例如能够指定插入模式的默认值。 如果没有动态数据,若要实现字段的默认值,必须附加到事件,使用 FindControl) 找到控件 (,并设置其值。 在 ASP.NET 4 中, EnableDynamicData 调用支持第二个参数,该参数允许你为对象上的任何字段传递默认值,如以下示例所示:
DetailsView1.EnableDynamicData(typeof(Product), new { ProductName = "DefaultName" });
声明性 DynamicDataManager 控件语法
DynamicDataManager 控件已得到增强,因此你可以以声明方式配置它,就像 ASP.NET 中的大多数控件一样,而不是仅在代码中配置它。 DynamicDataManager 控件的标记如以下示例所示:
<asp:DynamicDataManager ID="DynamicDataManager1" runat="server"
AutoLoadForeignKeys="true">
<DataControls>
<asp:DataControlReference ControlID="GridView1" />
</DataControls>
</asp:DynamicDataManager>
<asp:GridView id="GridView1" runat="server"
</asp:GridView>
此标记为 DynamicDataManager 控件的 DataControls 节中引用的 GridView1 控件启用动态数据行为。
实体模板
实体模板提供了一种自定义数据布局的新方法,无需创建自定义页面。 页面模板使用 FormView 控件 (而不是 DetailsView 控件,如早期版本的动态数据) 的页面模板和 DynamicEntity 控件用于呈现实体模板。 这使你可以更好地控制动态数据呈现的标记。
以下列表显示了包含实体模板的新项目目录布局:
\DynamicData\EntityTemplates
\DynamicData\EntityTemplates\Default.ascx
\DynamicData\EntityTemplates\Default_Edit.ascx
\DynamicData\EntityTemplates\Default_Insert.ascx
目录 EntityTemplate
包含有关如何显示数据模型对象的模板。 默认情况下,使用 Default.ascx
模板呈现对象,该模板提供的标记看起来与 ASP.NET 3.5 SP1 中动态数据使用的 DetailsView 控件创建的标记类似。 以下示例显示了 控件的 Default.ascx
标记:
<asp:EntityTemplate runat="server" ID="TemplateContainer1">
<ItemTemplate>
<tr
<td>
<asp:Label ID="Label1" runat="server" OnInit="Label_Init" />
</td>
<td>
<asp:DynamicControl runat="server" OnInit="DynamicControl_Init" />
</td>
</tr>
</ItemTemplate>
</asp:EntityTemplate>
可以编辑默认模板以更改整个网站的外观。 有用于显示、编辑和插入操作的模板。 可以基于数据对象的名称添加新模板,以便仅更改一种类型的对象的外观。 例如,可以添加以下模板:
\DynamicData\EntityTemplates\Products.aspx
模板可能包含以下标记:
<tr>
<td>Name</td>
<td><asp:DynamicControl runat="server" DataField="ProductName" /></td>
<td>Category</td>
<td><asp:DynamicControl runat="server" DataField="Category" /></td>
</tr>
使用新的 DynamicEntity 控件在页面上显示新的实体模板。 在运行时,此控件将替换为实体模板的内容。 以下标记显示使用实体模板的页面模板中的 Detail.aspx
FormView 控件。 请注意标记中的 DynamicEntity 元素。
<asp:FormView runat="server" ID="FormView1"
DataSourceID="DetailsDataSource"
OnItemDeleted="FormView1_ItemDeleted">
<ItemTemplate>
<table class="DDDetailsTable" cellpadding="6">
<asp:DynamicEntity runat="server" />
<tr class="td">
<td colspan="2">
<asp:DynamicHyperLink ID="EditHyperLink" runat="server"
Action="Edit" Text="Edit" />
<asp:LinkButton ID="DeleteLinkButton" runat="server"
CommandName="Delete"
CausesValidation="false"
OnClientClick='return confirm("Are you sure you want to delete this item?");'
Text="Delete" />
</td>
</tr>
</table>
</ItemTemplate>
</asp:FormView>
URL 和Email地址的新字段模板
ASP.NET 4 引入了两个新的内置字段模板: EmailAddress.ascx
和 Url.ascx
。 这些模板用于标记为 EmailAddress 或具有 DataType 属性的 URL 的字段。 对于 EmailAddress 对象,字段显示为使用 mailto: 协议创建的超链接。 当用户单击该链接时,它会打开用户的电子邮件客户端并创建主干消息。 类型化为 Url 的对象显示为普通超链接。
以下示例演示如何标记字段。
[DataType(DataType.EmailAddress)]
public object HomeEmail { get; set; }
[DataType(DataType.Url)]
public object Website { get; set; }
使用 DynamicHyperLink 控件创建链接
动态数据使用.NET Framework 3.5 SP1 中添加的新路由功能来控制最终用户在访问网站时看到的 URL。 使用新的 DynamicHyperLink 控件可以轻松生成指向动态数据网站中的页面的链接。 以下示例演示如何使用 DynamicHyperLink 控件:
<asp:DynamicHyperLink ID="ListHyperLink" runat="server"
Action="List" TableName="Products">
Show all products
</asp:DynamicHyperLink>
此标记基于文件中定义的Global.asax
路由创建指向表的“列表”页Products
的链接。 控件自动使用“动态数据”页所基于的默认表名称。
支持数据模型中的继承
实体框架和 LINQ to SQL 都支持其数据模型中的继承。 例如,具有 InsurancePolicy
表的数据库。 它还可能包含 CarPolicy
与 具有相同字段InsurancePolicy
的 和 HousePolicy
表,然后添加更多字段。 已修改动态数据,以了解数据模型中的继承对象并支持继承表的基架。
仅支持实体框架 (多对多关系)
实体框架对表之间的多对多关系提供丰富的支持,这是通过将关系公开为 Entity 对象上的集合来实现的。 添加了新的 ManyToMany.ascx
和 ManyToMany_Edit.ascx
字段模板,以支持显示和编辑多对多关系中涉及的数据。
用于控制显示和支持枚举的新属性
添加了 DisplayAttribute ,让你可以进一步控制字段的显示方式。 使用早期版本的动态数据中的 DisplayName 属性,可以更改用作字段描述文字的名称。 新的 DisplayAttribute 类允许指定用于显示字段的更多选项,例如字段的显示顺序以及字段是否用作筛选器。 属性还提供对 GridView 控件中用于标签的名称、 DetailsView 控件中使用的名称、字段的帮助文本以及用于字段 ((如果字段接受文本输入) )的水印的独立控件。
已添加 EnumDataTypeAttribute 类,以便将字段映射到枚举。 将此属性应用于字段时,需要指定枚举类型。 动态数据使用新 Enumeration.ascx
字段模板创建 UI 来显示和编辑枚举值。 模板将数据库中的值映射到枚举中的名称。
增强了对筛选器的支持
Dynamic Data 1.0 随附了布尔列和外键列的内置筛选器。 筛选器不允许指定是显示它们还是按何种顺序显示它们。 新的 DisplayAttribute 属性通过让你控制列是否显示为筛选器以及其显示顺序,解决了这两个问题。
另一项增强功能是已重新编写以使用 Web Forms 的新功能。 这样就可以创建筛选器,而无需了解将与之一起使用的数据源控件。 除了这些扩展,筛选器还已转换为模板控件,以便添加新控件。 最后,前面提到的 DisplayAttribute 类允许重写默认筛选器,其方式与 UIHint 允许替代列的默认字段模板的方式相同。
Visual Studio 2010 Web 开发改进
Visual Studio 2010 中的 Web 开发已得到增强,以提高 CSS 兼容性,通过 HTML 和 ASP.NET 标记代码段和新的动态 IntelliSense JavaScript 提高工作效率。
改进了 CSS 兼容性
Visual Studio 2010 中的 Visual Web 开发人员设计器已更新,以提高 CSS 2.1 标准符合性。 设计器可以更好地保留 HTML 源的完整性,并且比 Visual Studio 的早期版本更可靠。 在幕后,还进行了体系结构改进,这将更好地实现未来在呈现、布局和可维护性方面的增强。
HTML 和 JavaScript 代码段
在 HTML 编辑器中,IntelliSense 会自动完成标记名称。 IntelliSense 代码段功能可自动完成整个标记等。 在 Visual Studio 2010 中,JavaScript 支持 IntelliSense 代码片段,以及早期版本的 Visual Studio 中支持的 C# 和 Visual Basic。
Visual Studio 2010 包含 200 多个代码片段,可帮助你自动完成常见 ASP.NET 和 HTML 标记,包括必需的属性 ((如 runat=“server”) )和特定于标记 (的通用属性(如 ID、 DataSourceID、 ControlToValidate 和 Text) )。
可以下载其他代码片段,也可以编写自己的代码片段,用于封装你或你的团队用于常见任务的标记块。
JavaScript IntelliSense 增强功能
在 Visual 2010 中,JavaScript IntelliSense 经过重新设计,可提供更丰富的编辑体验。 IntelliSense 现在可识别由 registerNamespace 等方法和其他 JavaScript 框架使用的类似技术动态生成的对象。 性能已得到改进,可以分析大型脚本库并显示 IntelliSense,且处理延迟很少或根本没有。 兼容性已显著增强,支持几乎所有第三方库并支持不同的编码样式。 现在,在键入时会分析文档注释,并立即由 IntelliSense 利用。
使用 Visual Studio 2010 部署 Web 应用程序
ASP.NET 开发人员部署 Web 应用程序时,他们经常会发现遇到如下问题:
- 部署到共享托管站点需要 FTP 等技术,这可能很慢。 此外,必须手动执行运行 SQL 脚本等任务来配置数据库,并且必须更改 IIS 设置,例如将虚拟目录文件夹配置为应用程序。
- 在企业环境中,除了部署 Web 应用程序文件外,管理员还必须经常修改 ASP.NET 配置文件和 IIS 设置。 数据库管理员必须运行一系列 SQL 脚本才能运行应用程序数据库。 此类安装是劳动密集型的,通常需要数小时才能完成,必须仔细记录。
Visual Studio 2010 包括解决这些问题的技术,可让你无缝部署 Web 应用程序。 其中一项技术是 IIS Web 部署工具 (MsDeploy.exe) 。
Visual Studio 2010 中的 Web 部署功能包括以下主要领域:
- Web 打包
- Web.config 转换
- 数据库部署
- Web 应用程序的一键式发布
以下部分提供有关这些功能的详细信息。
Web 打包
Visual Studio 2010 使用 MSDeploy 工具为应用程序创建压缩的 (.zip) 文件,该文件称为 Web 包。 包文件包含有关应用程序的元数据以及以下内容:
- IIS 设置,包括应用程序池设置、错误页设置等。
- 实际的 Web 内容,包括网页、用户控件、静态内容 (图像和 HTML 文件) 等。
- SQL Server数据库架构和数据。
- 安全证书、要安装在 GAC 中的组件、注册表设置等。
Web 包可以复制到任何服务器,然后使用 IIS 管理器手动安装。 或者,对于自动部署,可以使用命令行命令或使用部署 API 安装包。
Visual Studio 2010 提供用于创建 Web 包的内置 MSBuild 任务和目标。 有关详细信息,请参阅 MSDN 网站上的 ASP.NET Web 应用程序项目部署概述 和 Vishal Joshi 博客上 应创建 Web 包的 10 + 20 个原因 。
Web.config 转换
对于 Web 应用程序部署,Visual Studio 2010 引入了 XML 文档转换 (XDT) ,该功能允许将文件从开发设置转换为 Web.config
生产设置。 转换设置在名为 、 web.release.config
等的web.debug.config
转换文件中指定。 (这些文件的名称与 MSBuild 配置匹配。) 转换文件仅包括对已 Web.config
部署文件进行的更改。 使用简单语法指定更改。
以下示例演示了可能为部署发布配置而生成的文件的一 web.release.config
部分。 示例中的 Replace 关键字 (keyword) 指定在部署期间,文件中的 connectionString 节点Web.config
将替换为示例中列出的值。
<connectionStrings xdt:Transform="Replace">
<add name="BlogDB" connectionString="connection string detail]" />
</connectionStrings>
有关详细信息,请参阅 MSDN 网站上的 Web.config Web 应用程序项目部署的转换语法和Web 部署:Vishal Joshi 博客上的 Web.Config 转换。
数据库部署
Visual Studio 2010 部署包可以包含SQL Server数据库的依赖项。 作为包定义的一部分,为源数据库提供连接字符串。 创建 Web 包时,Visual Studio 2010 会为数据库架构和数据创建 SQL 脚本(可选),然后将这些脚本添加到包。 还可以提供自定义 SQL 脚本,并指定它们在服务器上运行的顺序。 在部署时,提供适用于目标服务器的连接字符串;然后,部署过程使用此连接字符串运行创建数据库架构并添加数据的脚本。
此外,通过使用一键式发布,可以将部署配置为在将应用程序发布到远程共享托管站点时直接发布数据库。 有关详细信息,请参阅 Vishal Joshi 博客上的 如何:使用 Web 应用程序项目 部署数据库和使用 VS 2010 的数据库部署 。
One-Click Web 应用程序的发布
Visual Studio 2010 还允许使用 IIS 远程管理服务将 Web 应用程序发布到远程服务器。 可以为托管帐户或测试服务器或过渡服务器创建发布配置文件。 每个配置文件都可以安全地保存相应的凭据。 然后,可以使用 Web 一键发布工具栏一键部署到任何目标服务器。 使用 Visual Studio 2010,还可以使用 MSBuild 命令行发布。 这使你可以将团队生成环境配置为在持续集成模型中包括发布。
有关详细信息,请参阅 MsDN 网站上的 如何:使用 One-Click 发布和 Web 部署部署 Web 应用程序项目 和 Vishal Joshi 博客上的 Web 1-Click Publish with VS 2010 。 若要查看有关 Visual Studio 2010 中 Web 应用程序部署的视频演示文稿,请参阅 Vishal Joshi 上的 VS 2010 for Web 开发人员预览 版博客。
资源
以下网站提供有关 ASP.NET 4 和 Visual Studio 2010 的其他信息。
- ASP.NET 4 — MSDN 网站上的 ASP.NET 4 的官方文档。
- https://www.asp.net/ — ASP.NET 团队自己的网站。
- https://www.asp.net/dynamicdata/ 和 ASP.NET 动态数据内容映射 — ASP.NET 团队网站和 ASP.NET 动态数据官方文档中的联机资源。
- https://www.asp.net/ajax/— 用于 ASP.NET Ajax 开发的main Web 资源。
- https://devblogs.microsoft.com/dotnet/category/aspnet/ — Visual Web 开发人员团队博客,其中包括有关 Visual Studio 2010 中功能的信息。
- ASP.NET WebStack — ASP.NET 预览版的main Web 资源。
免责声明
这是一份初稿,并可能在本文所述软件最终商业发布之前进行大幅更改。
本文档中包含的信息代表 Microsoft Corporation 在发布之日对所讨论问题的当前观点。 由于 Microsoft 必须响应不断变化的市场条件,因此不应将其解释为 Microsoft 作出的承诺,并且 Microsoft 无法保证在发布日期之后提供的任何信息的准确性。
本白皮书仅用于提供信息。 MICROSOFT 对本文档中的信息不做任何明示、暗示或法定的担保。
用户有责任遵守所有适用的版权法/著作权法。 在不限制版权所辖权利的前提下,未经 Microsoft Corporation 的明确书面许可,本文档的任何部分不得被复制、存储或引进检索系统,或者以任何形式、任何方式(电子、机械、影印、录音等)或为任何目的进行传播。
Microsoft 可能拥有本文档所涵盖主题的专利、专利申请、商标、版权或其他知识产权。 除非 Microsoft 提供了明确的书面许可协议,否则提供本文档并不意味着赋予您这些专利、商标、版权或其他知识产权的任何许可。
除非另有说明,否则此处描述的示例公司、组织、产品、域名、电子邮件地址、徽标、人员、地点和事件都是虚构的,并且无意或应推断任何真实的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点或事件。
© 2009 年 Microsoft Corporation。 保留所有权利。
Microsoft 和 Windows 是 Microsoft Corporation 在美国和/或其他国家/地区的注册商标或商标。
此处提到的真实公司和产品的名称可能是其各自所有者的商标。