Integrated application pool mode When an application pool is in Integrated mode, you can take advantage of the integrated request-processing architecture of IIS and ASP.NET. When a worker process in an application pool receives a request, the request passes through an ordered list of events. Each event calls the necessary native and managed modules to process portions of the request and to generate the response. There are several benefits to running application pools in Integrated mode. First the request-processing models of IIS and ASP.NET are integrated into a unified process model. This model eliminates steps that were previously duplicated in IIS and ASP.NET, such as authentication. Additionally, Integrated mode enables the availability of managed features to all content types. Classic application pool mode When an application pool is in Classic mode, IIS 7.0 handles requests as in IIS 6.0 worker process isolation mode. ASP.NET requests first go through native processing steps in IIS and are then routed to Aspnet_isapi.dll for processing of managed code in the managed runtime. Finally, the request is routed back through IIS to send the response. This separation of the IIS and ASP.NET request-processing models results in duplication of some processing steps, such as authentication and authorization. Additionally, managed code features, such as forms authentication, are only available to ASP.NET applications or applications for which you have script mapped all requests to be handled by aspnet_isapi.dll. Be sure to test your existing applications for compatibility in Integrated mode before upgrading a production environment to IIS 7.0 and assigning applications to application pools in Integrated mode. You should only add an application to an application pool in Classic mode if the application fails to work in Integrated mode. For example, your application might rely on an authentication token passed from IIS to the managed runtime, and, due to the new architecture in IIS 7.0, the process breaks your application.

在IIS7中，DefaultAppPool和Classic .NET AppPool有什么区别?

原始来源:IIS体系结构介绍

在经典模式下，IIS直接使用ISAPI扩展和ISAPI过滤器。并使用两条管道，一条用于本机代码，另一条用于托管代码。您可以简单地在经典模式iis7中这样说。x就像iis6一样工作，并且您不会从iis7中获得额外的好处。x特性。

集成模式下，IIS和ASP。Net是紧密耦合的，而不是像经典模式那样仅仅依赖于Asp.net上的两个dll。

Integrated application pool mode When an application pool is in Integrated mode, you can take advantage of the integrated request-processing architecture of IIS and ASP.NET. When a worker process in an application pool receives a request, the request passes through an ordered list of events. Each event calls the necessary native and managed modules to process portions of the request and to generate the response. There are several benefits to running application pools in Integrated mode. First the request-processing models of IIS and ASP.NET are integrated into a unified process model. This model eliminates steps that were previously duplicated in IIS and ASP.NET, such as authentication. Additionally, Integrated mode enables the availability of managed features to all content types. Classic application pool mode When an application pool is in Classic mode, IIS 7.0 handles requests as in IIS 6.0 worker process isolation mode. ASP.NET requests first go through native processing steps in IIS and are then routed to Aspnet_isapi.dll for processing of managed code in the managed runtime. Finally, the request is routed back through IIS to send the response. This separation of the IIS and ASP.NET request-processing models results in duplication of some processing steps, such as authentication and authorization. Additionally, managed code features, such as forms authentication, are only available to ASP.NET applications or applications for which you have script mapped all requests to be handled by aspnet_isapi.dll. Be sure to test your existing applications for compatibility in Integrated mode before upgrading a production environment to IIS 7.0 and assigning applications to application pools in Integrated mode. You should only add an application to an application pool in Classic mode if the application fails to work in Integrated mode. For example, your application might rely on an authentication token passed from IIS to the managed runtime, and, due to the new architecture in IIS 7.0, the process breaks your application.

在IIS7中，DefaultAppPool和Classic .NET AppPool有什么区别?

原始来源:IIS体系结构介绍

IIS 6.0及以前版本:

ASP。NET通过ISAPI扩展和C API(基于C编程语言的API)与IIS集成，并公开了自己的应用程序和请求处理模型。

这有效地暴露了两个独立的服务器(请求/响应)管道，一个用于本地ISAPI过滤器和扩展组件，另一个用于托管应用程序组件。ASP。NET组件将完全在ASP. NET中执行。NET ISAPI扩展气泡，仅用于映射到ASP. NET的请求。NET中的IIS脚本映射配置。

请求非ASP。NET内容类型:图像、文本文件、HTML页面和无脚本的ASP页面由IIS或其他ISAPI扩展处理，对ASP.NET不可见。

这个模型的主要限制是ASP提供的服务。NET模块和自定义ASP。NET应用程序代码不能用于非ASP。网络请求

什么是脚本映射?

脚本映射用于将文件扩展名与请求该文件类型时执行的ISAPI处理程序关联起来。脚本映射还有一个可选设置，用于在允许处理请求之前验证与请求关联的物理文件是否存在

这里可以看到一个很好的例子

iis7及以上

IIS 7.0及以上版本已经从头开始重新设计，以提供一个全新的基于ISAPI的c++ API。

iis7.0及以上版本集成了ASP。NET运行时与Web服务器的核心功能，提供了一个统一的(单一的)请求处理管道，该管道公开给称为模块(IHttpModules)的本地和托管组件。

这意味着iis7可以处理任何内容类型的请求，包括NON ASP。asp.net模块/本机IIS模块和ASP。NET模块提供所有阶段的请求处理，这就是为什么NON ASP。NET内容类型(.html，静态文件)可以由.NET模块处理。

您可以构建新的托管模块(IHttpModule)，这些模块能够执行所有应用程序内容，并为您的应用程序提供一组增强的请求处理服务。 添加新的托管处理器(IHttpHandler)

经典模式(IIS6及以下版本中唯一的模式)是一种IIS仅直接使用ISAPI扩展和ISAPI过滤器的模式。事实上，在这种模式下，ASP。NET只是一个ISAPI扩展(aspnet_isapi.dll)和一个ISAPI过滤器(aspnet_filter.dll)。IIS只处理ASP。NET作为在ISAPI中实现的外部插件，并像黑盒一样使用它(仅当它需要向ASP.NET发出请求时)。在这种模式下，ASP。对于IIS, NET与PHP或其他技术没有太大区别。

Integrated mode, on the other hand, is a new mode in IIS7 where IIS pipeline is tightly integrated (i.e. is just the same) as ASP.NET request pipeline. ASP.NET can see every request it wants to and manipulate things along the way. ASP.NET is no longer treated as an external plugin. It's completely blended and integrated in IIS. In this mode, ASP.NET HttpModules basically have nearly as much power as an ISAPI filter would have had and ASP.NET HttpHandlers can have nearly equivalent capability as an ISAPI extension could have. In this mode, ASP.NET is basically a part of IIS.