伴随着VS2010的公开测试，ASP.NET4.0也进入了我们的视线。ASP.NET4.0究竟给我们带来了什么，将在哪些方面提高我们的生产力？
在何时你需要使用ASP.NET4.0开发你的网站程序？
需要更严格的遵守Web标准； 需要更流畅的Web Form开发方式；需要更好的搜索引擎优化； 需要后知后觉的纠正一些不够优良的设计，这些设计甚至可能是在ASP.NET 1.0发布之前就存在的； 需要将现有的功能重新改造为支持server farm或跨application domains； 需要将.NET调节和重组为一个
整体。
你不需要学习复杂的设计模式或各种SEO技巧，甚至不需要有代码重构的能力。忘记那些复杂的规定和教条吧，使用ASP.NET4.0提供的各种方便又实用的新功能，你将能轻松的开发/升级出与时俱进的高质量的程序。而这一切均需要从这里开始：
下载，安装VS2010 http://www.microsoft.com/visualstudio/zh-cn/products/2010/default.mspx#compare 安装之前务必卸载之前的测试版本，包括.NET Framework 4。新版本的VS2010包含了
大量更新，与之前的测试版本并不兼容 。新的预定义界面：
VS2010带来了一个新的预定义设置：Web Development(Code Only)，如字面所示，它是为了web开发而设计的，但与普通的Web Development模式不同的是，它针对的是喜欢手写代码的开发人员，它让VS看起来更像一个单纯的IDE：
至于您是否喜欢，就萝卜青菜，各有所爱了。。。（我还是喜欢全屏模式。。）
新的项目类型：
VS2010对ASP.NET的项目类型做了大量的更改，具体改动如下：
ASP.NET Web Service Application被完全的移除了；.Net3.0 带来的 WCF Service Application 移至 WCF projects 下； .Net3.5 SP1 带来的两个 Dynamic Data 相关的项目被改为更容易理解的名称，例如 Dynamic Data Web Application 使用LINQ to SQL替换了之前的Entity Framework； MVC项目有了一个称为 ASP.NET MVC2 Empty Web Application 的新选择。新的 ASP.NET MVC2 Empty Web Application 项目会建立如下的内容：标准的目录（空），空白的global.asax文件，web.config文件，标准的jQuery和MS AJAX库。相比较而言，ASP.NET MVC2 Web Application项目会生成一个可工作的网站，实现一个简单的membership模型，生成并使用master page，error page及所需的content page，并且可以生成一个示例test project。这对MVC新手非常有帮助，可以较为全面的使用MVC的功能。简洁的Web.Config文件
在VS2008SP1中，默认的web.config文件代码有139行，而在ASP.NET4.0中，web.config 文件只有6行：
原理很简单，ASP.NET团队对web.config文件进行了重构，将通用的设置写进默认的机器级别的web.config中。只剩下两个需要频繁变化的设置项。
debug的值在Web Application 项目中会被默认设置为true，在Web Site 项目中会被默认设置为false。 targetFramework的值可以设置为：4.0，3.5，3.0和2.0。这个选项会被IIS识别并自动赋予ASP.NET程序池相应的Framework版本。 Intellisense在旧版的web.config中会不起作用。可以通过删除原web.config中configuration的namespace（xmlns）属性就可以了。
*.config文件的层级结构：
在新的config文件定义中，一系列功能例如：Dynamic Data，routing与charting全部默认开启。
关于不同级别的config文件的关系，非常类似与CSS文件的复写。简单的来说就是离你越近的config权值越高，也就是最底层的machine.config权值最低，你新建的web项目中的web.config的权值最高。
root的config文件为machine.config，位于C:\Windows\Microsoft.NET\Framework\ v4.0.xyz\Config。 机器级别的web.config文件同样位于上面的那个目录，它在machine.config文件的基础上定义了web特定的一些节点的默认值，也就是在之前的ASP.NET版本中创建项目生成的web.config的文件中的那些值。 同样在上面那个目录中，你会发现如下的文件：web_hightrust.config, web_mediumtrust.config, web_lowtrust.config 和 web_minimaltrust.config。如果你的站点的信任级别不是“FULL”，将会使用对应的config文件作为默认值。 在你创建的项目中，会默认生成一个web.config文件，这也是我们通常所说的web.config文件。 在你的项目的任何目录中，你都可以添加一个web.config文件，这个文件中的值会覆盖项目根目录中的值。你可以利用这个特性做一些例如权限限制之类的功能。Config Transformation Files
这个新功能是为了应对同一个网站在不同服务器需要不同的web.config文件的问题，例如需要不同的connectionstring等。在以前我们可能很难维护这些不同的web.config文件（在我经历的项目中，为了解决这个问题，使用了com组建读取注册表，在不同机器的注册表中写入相应的信息），而现在有了这个新功能，我们可以以编程的方式统一的解决和处理这个问题（基于XPATH技术）。你只需要在web.config文件上右键单击，并选择“Add Config Transforms”即可。
Browscap.ini
对于使用过ASP的程序员来说，应该对这个文件并不陌生。这个文件是用来记录所有要使用的浏览器，以及这些浏览器所支持的特性（例如是否支持activeX）。
在.NET2.0中，微软将browsercap.ini的功能分割为一系列的*.browser文件。当收到一个请求的时候，我们就可以根据这个请求发起的browser找到对应的browser文件来获取浏览器的能力。这些数据会被传递到HttpBrowserCapabilities对象中，我们就可以使用这些数据了。
所有的browser文件可以在C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers下被找到。里面其实还是挺齐全的。
将一个文件分割成一系列文件会造成更加难以维护的情况，但这么做的理由似乎也不难猜想，就是微软希望一系列的浏览器使用同一个文件，例如ie.browser, mozilla.browser之类的。
在.NET4.0中，微软继续沿袭了这一思路，并且大范围的更新了这些文件，以支持现在流行的浏览器，特别是移动浏览器：iPhones, Windows PhoneOS, Android等，并且不会把这些浏览器简单的处理成wap浏览器。对于桌面浏览器来讲，也添加了对Firefox，Chrome和Safari的支持。
这么做很好，但是问题来了，难道我们要等每个新的.Net Framework发布后才能获得这些新的文件吗？答案当然是否定的。
如今浏览器发展日新月异，马上又即将有IE9, Opera 10.5, Gecko 1.9.3和新的IE for mobilephone等等。如果我们希望支持这些新的浏览器，我们有四种选择：
手动更新这些browser文件或者创建新的browser文件。 创建一个新的browser文件并将它添加在你的站点的App_Browser文件夹下。但这样只对你当前的站点有效。 扩展现有的browser capabilities provider。 创建一个自定义的browser capabilities provider替换现有的。
你可以针对你所拥有的资源或网站架构来选择如何解决这个问题。我们推荐使用自定义的browser capabilities provider去解决，虽然需要更多代码，但一旦完成，之后的更新将会更轻松。这就意味着你能更迅速的支持新的浏览器。
但无论如何，支持一个新的浏览器都是一个困难的工作，但.NET4.0给我们带来的最新的browser支持文件和一个可扩展的方法。
新的
Page属性
任何ASP.NET开发人员对于@Page标签都不会陌生。好消息是ASP.NET4.0完全兼容之前版本所提供的42个属性。更好的消息是，ASP.NET4.0还带来了6个新的属性，以应对日益复杂的开发需求：
ClientIDMode 顾名思义，这个属性用来定义ASP.NET将如何生成控件的客户端ID，如果你是一个前端开发人员，你将会
明白能够确定的控制客户端ID的生成将带来多大的便利。可能的值为AutoID(default/current)，Predictable，Static和Inherit。 ClientTarget 用来定义页面将针对哪个浏览器来执行。这将覆盖ASP.NET提供的自动浏览器识别功能，可能的应用场景为比如我们只需要支持IE浏览器或只需要支持FIREFOX等。 MetaDescription 顾名思义，用来生成页面的meta 的description标签。在我看来只是提供了一个更为官方的方法和方式，标准化了这一流程。 MetaKeywords 顾名思义，用来生成meta的keywords标签。 TargetSchema 用来定义验证页面所需的schema。这个标签只是用来标识的，并不会真正的执行。可以看作一种代码注释。 ViewStateMode 用来定义页面的VIEWSTATE是opt-in还是opt-out（默认）模式。
总体来说变化不大，提供了一些呼声很高的功能。
生成更纯净，更标准的HTML代码
这一直是ASP.NET中比较大的问题。ASP.NET1.1生成的html代码基本都不符合标准，这一点在ASP.NET 2.0中已经进行了改进，我们在web.config中引入了xhtmlConformance，用来定义控件将生成何种标准的HTML代码，默认为XHTML1.0 Transitional standard（Transitional）。相应的，我们可以将它设定为XHTML1.0 Strict（Strict）或者选择生成与ASP.NET1.1相同的HTML代码（Legacy，主要用来兼容从ASP.NET1.1升级而来的网站）。
不幸的是，在Legacy模式运行的网站与ASP.NET AJAX不兼容，而且尽管Transitional与Strict模式与XHTML标准兼容，但生成的代码对CSS也是非常不友好的。例如：
menu用table输出而不是UL/OL。 服务器端的控件属性例如 border=0 或disabled=disabled 是强制的并且无法移除。 对于支持template的控件，你可以对template内的代码进行任何的自定义，但无法移除最外层的table标签。
ASP.NET3.5带来的ListView，DataPager和CSS Control Adapters控件带来了过渡性的解决方案，ASP.NET4.0完全将他们集成在新版本的System.Web中，使得微软可以使ASP.NET 4.0可以尽可能的对CSS友好。毋庸置疑，生成干净的HTML标签是ASP.NET 4.0的重要目标之一。
ControlRenderingCompatibilityVersion
与xhltmlComformance类似，ASP.NET4.0为web.config带来了这个新的属性。当设置为3.5时，一切将和原来一致，但当你设置为4.0时，控件将按照全新的模式输出HTML代码：
xhtmlConformance被设置为Strict。 menu将会用UL/OL的形式输出。多余的HTML属性将被移除，甚至连validation的字体颜色也不会被设置为红色。 将可以对控件使用RenderOuterTable属性来控制是否输出外围的table标签。
在我看来这对于习惯使用控件的同学是个好消息。微软又帮你做了许多工作。
新增的一些小功能
列举一些新增的细节功能
内置<asp:chart>。 三种新的Redirect方式：Response.RedirectToRoute(HTTP302), Response.RedirectToRoutePermanent(HTTP301)和Response.RedirectPermanent(HTTP301)。 Inline的HTML encoded 字符串。
Routing配置更便捷。