IIS7应用程序池集成和经典的区别
IIS7应用程序池集成和经典的区别
IIS7应用程序池有集成和经典两种模式，根据微软官方的介绍，
集成模式，如果托管应用程序在采用集成模式的应用程序池中运行，服务器将使用 IIS 和 ASP.NET 的集成请求处理管道来处理请求。
经典模式，用经典模式的应用程序池中运行，服务器会继续通过 Aspnet_isapi.dll 路由托管代码请求，其处理请求的方式就像应用程序在 IIS 6.0 中运行一样。
所以理解集成和经典的区别，一个通俗的说法就是经典模式即继续使用IIS6的模式，也就是以前的模式。那么集成究竟有什么新的内容哪？
一个重要的说明，集成 .NET 模式下，应用程序不应在 <system.web>/<httpModules> 配置节中指定 ASP.NET 模块组件，而应使用 <system.webServer>/<modules> 配置节来加载 ASP.NET 模块组件。经典 .NET 模式 则是我们以前习惯的IIS 6 的方式，没有上述限制。
建议使用集成模式。
对IIS7经典模式和集成模式的理解
从IIS6新增应用程序池的概念，到现在IIS7，对HTTP请求处理功能已经越来越精确化和不断改善，IIS7应用程序池新增了经典模式和集成模式可供选择，不管官方还是一些书籍或文章都有介绍，但多数过于官方话，下面白话一下我对经典模式和集成模式的理解，希望能对自己以后和其他人更贴切的参考。涉及IIS解析ASP.NET的生命期等知识我就简单过一下，书籍和网络介绍的都比较多，本篇文章主要讲下我对经典模式和集成模式理解的区别和应用。
先直接看一个结果，再分析原因。编写一个最简单的网站，和一个最简单的HttpModule。
程序结构如上，第一个ModuleIISTests是一个网站，里面包括aspx和htm文件，default.aspx文件内容为空，a.htm文件内容为aaaaaa,下面一个TestIISModule是一个类库，TModule.cs是继承自IHttpModule的一个自定义的HtppModule，主要代码如下：
public void Init(HttpApplication context)
{
context.BeginRequest +=new EventHandler(context_BeginRequest);
}
public void context_BeginRequest(object sender, EventArgs e)
{
HttpApplication application = (HttpApplication)sender;
application.Response.Write("test module lawson");
}
然后配置网站的web.config如下：
。。。
<httpModules>
<add name="myModule" type="TestIISModule.TModule,TestIISModule"/>
</httpModules>
。。。
</system.web>
注意：这里是在system.web节点下。然后挂接IIS：
我添加了网站MyModule指向刚才程序开发的网站，引用程序池用的.net2.0经典模式，分别访问default.aspx和a.htm：
Default.aspx被module拦截了，输出了文字内容，但a.htm还是保持文件内容不变输出。
现在更改下web.config，首先删除刚才system.web节点下的httpModule节点，配置如下：
。。。
<modules>
<add name="myModule" type="TestIISModule.TModule,TestIISModule"/>
</modules>
。。。
</system.webServer>
注意：这里是在system.webServer节点下配置的，IIS集成模式下会读取该大节点下的modules,handlers等节点，然后把应用程序池改为集成模式，再刷新IIS，重新访问如下：
Default.aspx还是被拦截到了，但是这里a.htm也被拦截了。
截取微软官方一篇文章的图，介绍IIS7集成管道下的事件生命周期如下：
从该生命周期可以看出，集成模式下不管托管代码还是本机代码，都可以在身份验证和执行处理程序被插入到内核代码的托管代码拦截。在IIS6下，要想拦截本机代码，比如Htm文件，需要编写WIN32的非托管代码，但它也保留扩展的ISAPI，我们可以写托管代码拦截托管文件的请求。虽然IIS6也可以通过IIS插入ISAPI为aspnet_isapi.dll的扩展，处理对htm文件的拦截，但它实际会走两个通道，首先是IIS内部的本机代码拦截，然后是托管代码ISAPI的拦截。经典模式就是为了保留和IIS6一样的处理方式，以前开发的代码，可以方便的移植到IIS7上。
IIS7集成模式还增加了MapRequestHandler、LogRequest 和 PostLogRequest 事件，如果在经典模式下加了这些处理事件，会抛出：此操作要求使用 IIS 集成管线模式。如果集成模式下不让IIS处理不兼容集成模式的配置以及处理方式，可以在web.config中配置：
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
</system.webServer>即可。
实际上IIS7集成模式，就是让用户可以通过编写托管代码的handler等，把托管代码插入到IIS内核代码中来解析，方便大家精确控制任意请求，带来更好的扩展性。但缺点呢，我认为集成模式，任何文件请求都可能经过托管代码处理，别人不想把类试图片和静态文件用托管代码处理，就得想其他办法了，这样会不会内部效率降低，但这都是个人观点。
上面简单白话了一下我对IIS7集成模式和经典模式的理解，可能有表述不对的地方，欢迎拍砖。
1.定义
集成模式，如果托管应用程序在采用集成模式的应用程序池中运行，服务器将使用IIS和ASP.NET的集成请求处理管道来处理请求。
经典模式，用经典模式的应用程序池运行，服务器将会继续通过Aspnet_isapi.dll路由托管代码请求，其处理请求的方式就像应用程序在 IIS 6.0 中运行一样。
2.在IIS6.0的经典模式中，ASP.Net是一个添加到IIS中的ISAPI。在经典模式中IIS拥有自身的管道。这些管道可以通过创建一个ISAPI扩展进行扩充。ASP.NET只是ISAPI管道的一个组成部分。利用文件扩展名判断用那个ISAPI处理程序。
经典形式是为了与之前的版本兼容，运用ISAPI扩展来调用ASP.NET运转库，原先运转于IIS6.0下的Web应用程序迁移到IIS7.0中只需将应用程序配置成经典形式，代码根本不用修正就能够正常运转。
3.集成形式是一种统一的乞求处置管道，它将ASP.NET恳求管道与IIS中心管道组合在一同，这种形式可以提供更好的性能，可以完成配置和管理的模块化，而且增加了运用托管代码模块扩展IIS时的灵敏性。假设老的Web应用程序运转于IIS7.0的集成形式下，可能需求对应用程序的web.config文件停止修正，特别是运用了完成IHttpHandler接口的自定义模块的状况。IIS7.0在同一个效劳器上可以同时支持两种形式的应用程序。
4.web.config文件的变化.
system.webServer节指定了应用于web应用程序的IIS7.0设置，其父节点是configuration，该节点中能够设置的内容包括：当恳求未包含指定资源时，Web效劳器返回给客户端的默许文档(defaultDocument)； 响应的紧缩设置(httpCompression) 自定义头部(httpProtocol节的customHeaders) 模块（modules） 处置程序（handlers）其中的一些设置仅适用于集成形式，而不适用于经典形式，如经典形式下运转的应用程序则疏忽web.config的system.WebServer节中指定的一切托管代码模块和处置程序，这种形式下web应用程序应该在syste.web节的httpModules和httpHandlers中定义模块和处置程序。