IIS7.5应用程序池集成模式和经典模式的区别介绍_win服务器

在 IIS 7.5 中,应用程序池有两种运行模式:集成模式和经典模式。

应用程序池模式会影响服务器处理托管代码请求的方式。

如果托管应用程序在采用集成模式的应用程序池中运行,服务器将使用 IIS 和 ASP.NET 的集成请求处理管道来处理请求。

如果托管应用程序在采用经典模式的应用程序池中运行,服务器会继续通过 Aspnet_isapi.dll 路由托管代码请求,其处理请求的方式就像应用程序在 IIS 6.0 中运行一样。

经典模式:

  指的是与IIS 6或者之前版本保持兼容的一种模式,一个典型问题就是,在处理ASP.NET这种动态网站的时候,它是通过一个所谓的ISAPI程序,作为插件的方式来工作的。针对不同的动态应用程序(例如ASP,PHP等),会需要不同的ISAPI。

集成模式:

  这种全新的模式,允许我们将ASP.NET更好地与IIS集成,甚至允许我们在ASP.NET中编写一些功能(例如Module)来改变IIS的行为(扩展)。集成的好处是,不再通过ISAPI的方式,提高了速度和稳定性。至于扩展,则可以使得我们对于IIS以及其他类型的请求有更多的控制。

升级过程中出现了比较多的问题,前面文章也提到过几个。这次就主要介绍下httpHandler 和 httpModule 在集成和经典模式下的区别。很多文件上传等都是需要使用到httpModule去实现。我今天就出现了NeatUpload在iis7.5下出现未将对象引用到设计实例的错误。所以用httpModule作为测试案例。

1.新建测试网站WebApplication,加入MyHttpModule类实现IHttpModule接口,主要目的是测试程序是否经过了HttpModule,经过的在页面输出HttpModule字符。

public class MyHttpModule : IHttpModule
{
public void Dispose()
{
}
public void Init(HttpApplication context)
{
context.BeginRequest += context_BeginRequest;
}
protected void context_BeginRequest(object sender, EventArgs e)
{
var context = sender as HttpApplication;
context.Response.Clear();
context.Response.Write("HttpModule");
context.Response.End();
}
}

2、2.在IIS7.5部署网站,首先使用经典模式应用程序池。在web.config的 <system.web> 的子节点<httpModules> 加入<add name="MyHttpModule" type="WebApplication.MyHttpModule, WebApplication"/>

<httpHandlers>
<remove verb="*" path="*.asmx"/>
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add verb="*" path="*_AppService.axd" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" validate="false"/>
</httpHandlers>
<httpModules>
<add name="MyHttpModule" type="WebApplication.MyHttpModule, WebApplication"/>
<add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
</httpModules> 

访问网站可以发现页面输出如下,说明程序经过了HttpModule

直接切换应用程序池成集成模式会发现页面输出为空。证明程序没有经过HttpModule。那在集成模式下HttpModule如何才能执行呢? 之前部署URLRewriter的时候查资料只知道需要 <system.webServer> <modules>注册HttpModule。仔细查看配置文件会发现有一段如下英文.意思大概就是iis7版本的设置。之前版本无需设置。
<!--
The system.webServer section is required for running ASP.NET AJAX under Internet
Information Services 7.0. It is not necessary for previous version of IIS.
-->
这样就大概明白意思是iis7.0之后有部分web配置移动到system.webServer中。查阅相关得到答案确实如此 详细资料见 http://www.cnblogs.com/buaaboyi/archive/2011/01/20/1939903.html

于是在<system.webServer> <modules>中加入配置如下,刷新页面,页面能够输出字符HttpModule,证明成功了。

<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<modules>
<remove name="ScriptModule" />
<add name="MyHttpModule" type="WebApplication.MyHttpModule, WebApplication"/>
<add name="ScriptModule" preCondition="managedHandler" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
</modules>

由于在升级过程成有一个站点出现 HTTP 错误 500.22 - Internal Server Error 检测到在集成的托管管道模式下不适用的 ASP.NET 设置


当时在比较急的情况下就直接删除了 <system.web> 的子节点<httpModules> 程序正常运行。后面通过仔细和正常的站点对比是发现是缺少 <validation validateIntegratedModeConfiguration="false"/> 这个导致,这个主要作用是设置不检测 <system.web>中的配置

经过这今天的折腾终于是对iis7.5上的部署有了一定了解了。

以上是小编为您精心准备的的内容,在的博客、问答、公众号、人物、课程等栏目也有的相关内容,欢迎继续使用右上角搜索按钮进行搜索集成模式
经典模式
iis7.5应用程序池设置、iis7.5应用程序池优化、iis7.5应用程序池回收、iis7.5应用程序池监控、iis7.5应用程序池配置,以便于您获取更多的相关知识。

时间: 2024-10-02 02:12:05

IIS7.5应用程序池集成模式和经典模式的区别介绍_win服务器的相关文章

IIS7 经典模式和集成模式的区别分析_win服务器

经典模式是为了与之前的版本兼容,使用ISAPI扩展来调用ASP.NET运行库,原先运行于IIS6.0下的Web应用程序迁移到IIS7.0中只要将应用程序配置成经典模式,代码基本不用修改就可以正常运行.集成模式是一种统一的哀求处理管道,它将ASP.NET请求管道与IIS核心管道组合在一起,这种模式能够提供更好的性能,能够实现配置和治理的模块化,而且增加了使用托管代码模块扩展IIS时的灵活性.假如老的Web应用程序运行于IIS7.0的集成模式下,可能需要对应用程序的web.config文件进行修改,

服务器授权模式每服务器同时连接数与每设备或每用户的区别小结_win服务器

服务器授权模式每服务器,同时连接数与每设备或每用户的区别每服务器认证:指允许服务可以同时有多少个并发客户端用户访问的数量:每客户认证:指你的每个客户端都有认证许可,客户端通过这个认证访问服务器:举例如下:公司有两台服务器:Server1,Server2;客户端:100台:若你选择每服务器认证,这个你就需要为Server1,Server2各选择100个认证,共计200个认证,才能满足100个客户端同时访问:若你选择每客户认证,你只需100个客户认证,就能满足100个客户端访问的需求: 用户可以根据

IIS7 配置大全(ASP.NET 2.0, WCF, ASP.NET MVC,php)_win服务器

一.IIS7.0 配置 ASP.NET2.0     1.ASP.NET 2.0 部署 1)首先打开win7 的特性,路径我已标注 下面选中的是ASP.NET2.0, 如果要支持ASP.NET1.1,你的选中IIS6兼容 2.)设置安全选项 3)添加.Net经典应用程序池 4)将站点转换为Application 5)为站点添加 yourmachinename\IIS_IUSRS权限 6.)右键站点-Manage Application-Advanced Setting 设置当前站点为Classi

IIS7配置PHP环境图文教程(fastcgi快速最新版)_win服务器

我们知道php配置有几种: 1.CGI方式加载PHP环境,通常就是IIS里面配置解释器为php.exe,早期比较常见,目前使用较少. 特点是:稳定,但效率太低. 2.ISAPI方式加载PHP环境,通常就是IIS里面配置解释器为php5isapi.dll,目前使用最多,应用最广. 特点是:多线程,效率较高,但不够稳定. 3.FastCGI方式加载PHP环境,在IIS环境里并不常见,但其它系统环境应用还是有的,不过IIS7.0开始内置FastCGI了. 特点是:高效率,高稳定性,属于将来发展趋势.

64位系统中IIS7运行ASP时出现ADODB.Connection 800a0e7a错误的解决方法_win服务器

今天将一个ASP网站拷贝到64位的Windows7中运行,IIS7安装都没有问题,可就是死活运行不了,总是出现ADODB.Connection错误"800a0e7a",真是奇怪,之前在XP中运行一点问题都没有的.起初以为是代码上的原因,于是写一段最简单的连接数据库的代码,还是出错,研究半天终于找到了解决方法,拿来分享. 原因是因为在64位Windows7操作系统中,IIS7应用程序池默认没有启用32位应用程序,而我们连接ACCESS数据库的驱动程序Microsoft.Jet.OLEDB

iis 创建应用程序池的方法与分析第1/3页_win服务器

当 IIS 6.0 在工作进程隔离模式下运行时,可将 Web 应用程序组合到应用程序池中.应用程序池允许将特定配置设置应用于多个应用程序组,并允许工作进程为这些应用程序提供服务.可向应用程序池指定任何 Web 目录或虚拟目录. 通过创建新应用程序池并向它们指定网站和 Web 应用程序,可提高服务器的效率和可靠性,并使其他应用程序即使在新应用程序池终止时也总是可用. 要点 您必须是本地计算机上 Administrators 组的成员或者必须被委派了相应的权限,才能执行下列步骤.作为安全性的最佳*作

IIS 6.0 应用程序池回收和工作进程使用介绍_win服务器

     公司的一个网站程序长时间运行后,速度变慢,重新启动网站后速度明显变快,估计是网站程序占用的内存和CPU资源没能及时释放,才需要每隔一段时间重启网站释放资源.但手工重启总不能算解决问题的方法,怎样才能实现自动管理呢?IIS6.0的应用程序池自动回收功能可以解决这一问题.       应用程序池是将一个或多个应用程序链接到一个或多个工作进程集合的配置.因为应用程序池中的应用程序与其他应用程序被工作进程边界分隔,所以某个应用程序池中的应用程序不会受到其他应用程序池中应用程序所产生的问题的影响

在IIS7中应用Application Request Routing配置反向代理的图文教程_win服务器

在配置web服务器的时候,我们经常遇到这样的问题,由于某些原因,该服务器只能拥有一个公网IP,但是可能需要提供其他机器或者本机上其他webserver的服务器给访问者,同时又不希望使用其他端口,如果在linux下,常见的解决方案是使用nginx作为前端server,通过反向代理间接访问其他webserver.在IIS7之前,在windows上要实现该功能却不是一件容易的事情,但是在IIS7上,通过Application Request Routing模块,我们可以轻松实现反向代理. 本次测试配置

IIS7.5 Error Code 0x8007007e HTTP 错误 500.19的解决方法_win服务器

今天在win2008+IIS7.5的环境中部署WCF服务后,一直出现无法打开的页面.具体错误信息如下: HTTP 错误 500.19 - Internal Server Error   无法访问请求的页面,因为该页的相关配置数据无效.    详细错误信息    模块 DynamicCompressionModule    通知 SendResponse    处理程序 StaticFile    错误代码 0x8007007e    请求的 URL ***    物理路径 C:/ECG2.0/e