IIS7中Integrated和classic的区别

Posted 2023-05-11

IIS7的两种模式和IIS6有什么区别？长话短说：
IIS7.0 Integrated mode： asp.net 的modules和handlers从<system.webServer>下的<modules> 和<handlers>里读取，以前的<system.web>下的<httpModules> 和<httpHandlers>配置节会被忽略，如果设置禁止验证（disabled validation），是不会产生错误的。
IIS7的Application Pools有两种mode，一种是Integrated，一种是classic。如果使用Integrated模式，那么对自定义的 httpModules和httpHandlers就要修改配置文件了，需要将他们转移到<modules> 和<hanlders>节里去。
IIS7.0 Classic mode： 与 以上情况是相反的，<modules>和<handlers>会被忽略。
IIS6.0 ： 这个大家都不陌生了。 参考技术A 在 IIS 7.0 中，应用程序池的两种运行模式：集成模式和经典模式。
应用程序池模式会影响服务器处理托管代码请求的方式。
如果托管应用程序在采用集成模式的应用程序池中运行，服务器将使用 IIS 和 ASP.NET 的集成请求处理管道来处理请求。
如果托管应用程序在采用经典模式的应用程序池中运行，服务器会继续通过 Aspnet_isapi.dll 路由托管代码请求，其处理请求的方式就像应用程序在 IIS 6.0 中运行一样。本回答被提问者采纳 参考技术B IIS7的Application
Pools有两种mode，一种是Integrated，一种是classic。如果使用Integrated模式，那么对自定义的
httpModules和httpHandlers就要修改配置文件了，需要将他们转移到<modules>
和<hanlders>节里去。
IIS7的两种模式和IIS6有什么区别？长话短说：
IIS7.0 Integrated mode： asp.net
的modules和handlers从<system.webServer>下的<modules>
和<handlers>里读取，以前的<system.web>下的<httpModules>
和<httpHandlers>配置节会被忽略，如果设置禁止验证（disabled validation），是不会产生错误的。
IIS7.0 Classic mode： 与 以上情况是相反的，<modules>和<handlers>会被忽略。
IIS6.0 ： 这个大家都不陌生了。
如果做一个可以在IIS6和IIS7的两种mode下都可以运行的配 置？validateIntegratedModeConfiguration=“false”是做什么用的？有需要的朋友可以 在这里查看 详情。
其次，从iis6迁移到iis7上后，有些url rewrite功能可能就不好用了， 下面这篇文章讲述了一个hack方法 ，有效的控制了staticFile
handler的职责，实现了像iis6那样的工作方式。

IIS7.0中的Web应用程序有两种配置模式：经典模式和集成模式。两者区别大家可以参考下，根据实际情况选用。
经典模式是为了与之前的版本兼容，使用ISAPI扩展来调用ASP.NET运行库，原先运行于IIS6.0下的Web应用程序迁移到IIS7.0中只要将应用程序配置成经典模式，代码基本不用修改就可以正常运行。集成模式是一种统一的哀求处理管道，它将ASP.NET请求管道与IIS核心管道组合在一起，这种模式能够提供更好的性能，能够实现配置和治理的模块化，而且增加了使用托管代码模块扩展IIS时的灵活性。假如老的Web应用程序运行于IIS7.0的集成模式下，可能需要对应用程序的web.config文件进行修改，尤其是使用了实现IHttpHandler接口的自定义模块的情况。IIS7.0在同一个服务器上能够同时支持两种模式的应用程序。

IIS6.0中ASP.NET
MMC管理单元用于配置ASP.NET，7.0中ASP.NET应用程序的管理域IIS管理更加紧密的集成在一起，不存在单独的管理单元，所有的IIS和ASP.NET配置都是使用IIS管理器完成的。IIS7.0配置信息基于.NET

framework配置系统，所以IIS7.0中运行的应用程序的web.config文件同时包含web服务器和ASP.NET配置设置，例如可以再web.config文件中设置扩展名和文件的映射（IIS6.0中必须在IIS中进行配置）。

web.config文件的变化

system.webServer节指定了应用于web应用程序的IIS7.0设置，其父节点是configuration，该节点中可以设置的内容包括：

当请求未包含指定资源时，Web服务器返回给客户端的默认文档(defaultDocument)； 响应的压缩设置(httpCompression)
自定义头部(httpProtocol节的customHeaders) 模块（modules） 处理程序（handlers）

其中的一些设置仅适用于集成模式，而不适用于经典模式，如经典模式下运行的应用程序则忽略web.config的system.WebServer节中指定的所有托管代码模块和处理程序，这种模式下web应用程序应该在syste.web节的httpModules和httpHandlers中定义模块和处理程序。

将 Web 应用程序迁移到集成模式

不包含自定义模块或处理程序的 Web 应用程序通常无需更改即可在 IIS 7.0 集成模式下正常工作。对于依靠于自定义模块或处理程序的 Web 应用程序，需要执行以下步骤来使其能够在集成模式下运行：

使用本主题稍后的将 Web Config 文件迁移到集成模式部分中描述的方法之一，在 Web.config 文件的 system.webServer 节中注册自定义模块和处理程序。

仅在自定义模块的 Init 方法中定义 HttpApplication 请求管道事件（如 BeginRequest 和 EndRequest）的事件处理程序。

请确保您已解决 Upgrading ASP.NET Applications to IIS 7.0: Differences between
IIS 7.0 Integrated Mode and Classic mode（将 ASP.NET 应用程序升级到 IIS 7.0：IIS
7.0 集成模式和经典模式之间的区别）的“Known Differences Between Integrated Mode and
Classic Mode”（集成模式和经典模式之间的已知区别）部分中讨论的问题。

实现 IHttpModule 接口的模块被称为托管代码模块，因为它们是使用 .NET framework
生成的。可以在服务器级别或应用程序级别注册托管代码模块。本机代码模块是仅在服务器级别注册的
DLL（非托管代码）。在集成模式下，将以托管模块的形式实现核心 ASP.NET 功能，例如会话状态和 Forms 身份验证。

在将应用程序从经典模式迁移到集成模式时，可以保留经典模式下的自定义模块和处理程序注册，也可以将这些注册移除。如果不移除经典模式下使用的
httpModules 和 httpHandlers 注册，则必须将 validation 元素的
validateIntegratedModeConfiguration 属性设置为 false 以避免错误。validation 元素是
system.webServer 元素的子元素。有关更多信息，请参见 ASP.NET Integration with IIS 7.0（将
ASP.NET 与 IIS 7.0 集成）中的“Disabling the migration message”（禁用迁移消息）部分。

迁移 Web.config 文件以便在集成模式下使用

如果模块或处理程序是在应用程序级别定义的，则不会自动调用该模块或处理程序。这涉及符合以下条件的模块或处理程序：在 Bin
文件夹下的程序集中定义；在 App_Code 文件夹下作为源代码定义；没有在 Web.config 文件的 system.webServer
节中注册和定义。为了使模块或处理程序能够参与集成模式请求管道，必须使用下列方法之一注册该模块或处理程序：

直接编辑 Web.config 文件，并且将 modules 或 handlers 元素添加到 system.webServer
元素中。请注重，与经典模式相比，元素名称是不同的：modules 和 handlers 分别对应于经典模式下的 httpModules 和
httpHandlers。

使用 IIS 管理器配置模块或处理程序。有关更多信息，请参见 Configuring Handler Mappings in IIS 7.0（在
IIS 7.0 中配置处理程序映射）和 Configuring Modules in IIS 7.0（在 IIS 7.0 中配置模块）。

使用 IIS 7.0 命令行工具 (Appcmd.exe)。有关更多信息，请参见 Configure Settings for a Site
Application Virtual Directory or URL by Using Appcmd.exe（使用 Appcmd.exe
配置站点、应用程序、虚拟目录或 URL 的设置）。

用来使用集成模式的类和属性

在 IIS 7.0 集成模式以及 .NET framework 3.0 版或更高版本中使用应用程序时，可以使用下面这些在经典模式下不可用的类和成员：

HttpResponse 对象的 SubStatusCode 属性，使用它可以设置在配置了失败请求跟踪的情况下有用的代码。有关更多信息，请参见
Troubleshooting Failed Requests Using Failed Request Tracing in IIS
7.0（使用 IIS 7.0 中的跟踪功能解决请求失败的问题）。

HttpResponse 对象的 Headers 属性，使用它可以访问响应头。

HttpContext 对象的 IsPostNotification 和 CurrentNotification 属性，在提供 HttpApplication 事件的处理程序时可以使用它们。

HttpRequest 对象的 Headers 和 ServerVariables 属性，它们支持写功能。

IIS7 中的 DefaultAppPool 和 Classic .NET AppPool 有啥区别？

【中文标题】IIS7 中的 DefaultAppPool 和 Classic .NET AppPool 有啥区别？

【英文标题】：What is the difference between DefaultAppPool and Classic .NET AppPool in IIS7?IIS7 中的 DefaultAppPool 和 Classic .NET AppPool 有什么区别？

【发布时间】：2010-10-20 01:07:38

【问题描述】：

我在 IIS 中遇到超时问题。在 web.config 中，会话超时设置为 60 分钟，但 20 分钟后会话结束。

此问题仅在 IIS7 中出现，在 IIS5 中不会出现。

经过一番调查，我发现这是由于应用程序池超时。如果 App Pool 有 20 分钟没有做任何事情，IIS 将结束会话。

如果应用程序使用的是 defaultAppPool，这总是会发生，但如果我将应用程序池更改为经典的 .NET 应用程序池，则不会发生超时。

两种模式都有空闲超时，但只有在 DefaultAppPool 中会发生这种情况。

这是为什么呢？ 成为 Classic .NET AppPool 和 DefaultAppPool 有什么区别？ Classic 和 Integrated 之间的管道有何区别？

【参考方案1】：

经典池通过使用 IIS 和 ISAPI 的单独处理管道来处理应用程序池中的请求。集成使用集成管道，IIS 和 ASP.NET a（更好的性能）利用仅使用一个进程的 IIS 7.0 的改进功能。 好的做法是为每个应用创建一个新的应用池，然后根据应用需求单独配置。

---

经典模式遵循以下步骤：

1.传入的HTTP请求是通过IIS核心接收的。

2.通过ISAPI处理请求。

3.通过ASP.NET处理请求。

4.请求通过ISAPI回传。

5.请求通过 IIS 核心返回，最终传递 HTTP 响应

---

集成模式使用：

1.传入的HTTP请求是通过IIS核心和ASP.NET接收的。

2.适当的处理程序执行请求并传递 HTTP 响应

增加 web.config 中的会话超时时间

请记住，增加这会导致应用程序消耗更多资源，例如内存

【参考方案2】：

我认为你的问题已经有了答案。 IIS 6 和 7 有一个应用程序池超时的概念，这与会话超时不同。

模式之间有什么区别...已经解决。我不确定您关于管道和模式差异的问题如何与您的问题相关 - 超时。

一些观点：空闲超时不会发生在有任何流量的网站上。您可能遇到了仅出现在 QA 站点或您的开发箱中的问题。空闲超时设置的存在是为了节省您的开发箱和每月 5 美元的托管公司的资源，这些公司有很多未充分利用的网站（例如我的博客）。您可能不希望公共站点上的空闲超时。

会话超时 - 在网络配置中设置，如果用户没有访问服务器，他们的会话超时。

空闲超时 20 分钟内根本没有人接触网络服务器，因此请关闭以节省资源。在IIS 6 中，它位于应用程序池的性能选项卡上 - 并且很容易禁用。在 IIS 7 中，您可以在应用程序池高级设置或processModel element 中进行设置。我运行的 IIS 7 不如 IIS 6 多，但看起来从 web.config 中删除元素或设置为 0 会获得无限空闲超时。

【参考方案3】：

DefaultAppPool 会忽略 web.config 中的会话超时设置，但 ASPNet 应用程序池将使用 web.config 中的设置。

【参考方案4】：

IIS7 进行了一些重大更改以更好地支持 WCF，其中一个关键部分是新的集成应用程序池。本次 PDC 会议从提高 WCF 服务性能的角度讨论了其中的一些挑战：http://channel9.msdn.com/pdc2008/TL38/

此页面很好地概述了 IIS7 架构：http://learn.iis.net/page.aspx/101/introduction-to-iis7-architecture/。 我在本文中包含了一些关于以下两种不同类型的应用程序池用途的关键信息：

集成应用程序池模式

当应用程序池在 集成模式，你可以拿 综合优势 IIS的请求处理架构 和 ASP.NET。当一个工作进程在 一个应用程序池接收一个 请求，请求通过 事件的有序列表。每个事件 调用必要的本地和托管 处理部分的模块 请求并生成响应。 跑步有几个好处 集成模式下的应用程序池。 首先是请求处理模型 IIS 和 ASP.NET 被集成到一个 统一的流程模型。该型号 消除了以前的步骤 在 IIS 和 ASP.NET 中重复，例如 验证。此外， 集成模式使 托管功能的可用性 所有内容类型。

经典应用池模式

当应用程序池处于经典模式时 模式下，IIS 7.0 处理请求的方式如下 IIS 6.0 工作进程隔离模式。 ASP.NET 请求首先通过 IIS 中的本机处理步骤 然后路由到 Aspnet_isapi.dll 托管代码的处理 托管运行时。最后，请求 通过 IIS 路由返回以发送 回复。 IIS 的这种分离 和 ASP.NET 请求处理模型 导致一些重复 处理步骤，例如 身份验证和授权。 此外，托管代码功能， 如表单身份验证，仅 可用于 ASP.NET 应用程序或 您有脚本的应用程序 映射要处理的所有请求 aspnet_isapi.dll。一定要测试你的 现有的应用程序 集成模式下的兼容性 在升级产品之前 环境到 IIS 7.0 并分配 应用程序池中的应用程序 集成模式。你应该只添加 应用程序池的应用程序 如果应用程序在经典模式下 无法在集成模式下工作。为了 例如，您的应用程序可能依赖 在从传递的身份验证令牌上 IIS 到托管运行时，并且，由于 到 IIS 7.0 中的新架构， 该过程会破坏您的应用程序。