提问



我昨晚部署了一个ASP.NET MVC应用程序,并发现将IIS7设置为集成模式进行部署的工作量较少。我的问题是有什么区别?使用其中一个有什么含义?

最佳参考


经典模式(IIS6及更低版本中的唯一模式)是一种模式,其中IIS仅直接与ISAPI扩展和ISAPI过滤器一起使用。实际上,在这种模式下,ASP.NET只是一个ISAPI扩展(aspnet_isapi.dll)和一个ISAPI过滤器(aspnet_filter.dll)。 IIS只是将ASP.NET视为在ISAPI中实现的外部插件,并且像黑盒一样使用它(只有当它需要向ASP.NET发出请求时)。在这种模式下,ASP.NET并不多与PHP或其他IIS技术不同。


另一方面,集成模式是IIS7中的一种新模式,其中IIS管道与ASP.NET请求管道紧密集成(即完全相同)。 ASP.NET可以看到它想要的每个请求,并在整个过程中操纵事物。 ASP.NET不再被视为外部插件。它完全融合并集成在IIS中。在这种模式下,ASP.NET HttpModule基本上具有与ISAPI过滤器相同的功能,ASP.NET HttpHandler可以具有几乎相同的功能作为ISAPI扩展的功能可能具有。在这种模式下,ASP.NET基本上是IIS的一部分。

其它参考1



  集成应用程序池模式

  
  当应用程序池处于集成模式时,您可以利用它
  IIS和ASP.NET的集成请求处理体系结构。
  当应用程序池中的工作进程收到请求时,
  请求通过有序的事件列表。每个事件都会调用
  必要的本机和托管模块来处理部分内容
  请求并生成响应。

  
  在Integrated中运行应用程序池有几个好处
  模式。首先是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之前的集成模式
  并以集成模式将应用程序分配给应用程序池。
  您应该只将应用程序添加到Classic中的应用程序池
  模式,如果应用程序无法在集成模式下工作。例如,
  您的应用程序可能依赖于从IIS传递的身份验证令牌
  到受管运行时,并且,由于IIS 7.0中的新体系结构,
  这个过程会破坏你的申请。



摘自:IIS7中的DefaultAppPool和Classic .NET AppPool有什么区别?


原始来源:IIS架构简介[9]

其它参考2



   IIS 6.0及以前的版本:



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


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


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


此模型的主要限制是ASP.NET模块提供的服务和自定义ASP.NET应用程序代码不可用于非ASP.NET请求


什么是SCRIPT MAP?


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


一个很好的例子可以是 seen here [10]



   IIS 7及以上



IIS 7.0及更高版本已经从头开始重新设计,以提供基于ISAPI的全新C ++ API。


IIS 7.0及更高版本将ASP.NET运行时与Web服务器的核心功能集成在一起,提供统一(单个)请求处理管道,该管道暴露给称为模块的本机和托管组件(IHttpModules)


这意味着IIS 7处理任何内容类型的请求,NON ASP.NET Modules / native IIS modulesASP.NET modules在所有阶段提供请求处理 这就是为什么.NET模块可以处理非ASP.NET内容类型(.html,静态文件)。



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

  • 添加新的托管处理程序( IHttpHandler )


其它参考3


在经典模式下,IIS直接使用ISAPI扩展和ISAPI过滤器。并使用两个管道线,一个用于本机代码,另一个用于托管代码。您可以简单地说,在经典模式下,IIS 7.x与IIS 6一样工作,并且您无法从IIS 7.x功能中获得额外的好处。[11] [12]


在集成模式下,IIS和ASP.Net紧密耦合,而不是依赖于Asp.net上的两个DLL,就像经典模式一样。

其它参考4


经典模式
通常,将Web应用程序从IIS 6.0移动到IIS 7.0经典模式只需要将应用程序放在以经典模式运行的应用程序池中。例如,当您使用安装IIS 7.0时,默认情况下Web服务器配置为在集成模式下运行。它还配置为在默认应用程序池下运行,该池名为DefaultAppPool。要在经典模式下运行Web应用程序,请使用Classic.NETAppPool应用程序或创建配置为在经典模式下运行的新应用程序池。有关如何创建应用程序池的信息,请参阅创建应用程序池。
在经典模式下运行的应用程序中实现IHttpModule接口的任何自定义模块仅会通知ASP.NET运行时处理的管道请求。例如,他们会收到有关.aspx页面请求的通知。 Classic模式的应用程序生命周期与IIS 6.0中ASP.NET的生命周期相同。有关更多信息,请参阅IIS 5.0和6.0的ASP.NET应用程序生命周期概述。
如果在经典模式下运行的应用程序包含需要脚本映射来处理IIS中的自定义扩展的处理程序,则必须在httpHandler组和处理程序组中注册该处理程序。通过在handler元素中指定modules和scriptProcessor属性,将自定义文件扩展名映射到ASP.NET ISAPI扩展(Aspnet_isapi.dll)。这些属性指定定义处理程序的模块是ISAPI扩展,并指定该扩展的路径。这就是经典模式下的IIS 7.0如何提供与早期版本的IIS的向后兼容性。但是,如果以集成模式运行应用程序,则必须删除模块和scriptProcessor属性。有关更多信息,请参见如何:在IIS中配置HTTP处理程序扩展。
将Web应用程序从IIS 6.0移动到经典模式时,无法保证在没有更改的情况下在集成模式下工作。如果将应用程序从经典模式切换到集成模式(并更改任何自定义模块和处理程序),则可能必须进行其他更改才能使应用程序在集成模式下正确运行。本主题的下一部分介绍如何将应用程序移动到IIS 7.0集成模式。


集成模式
不包含自定义模块或处理程序的Web应用程序通常在IIS 7.0中的集成模式下无需更改即可运行。依赖于自定义模块或处理程序的Web应用程序需要执行以下步骤才能使应用程序在集成模式下运行:
通过使用本主题后面的将Web配置文件迁移到集成模式部分中描述的方法之一,在Web.config文件的system.webServer部分中注册自定义模块和处理程序。
仅在自定义模块的Init方法中为HttpApplication请求管道事件(如BeginRequest和EndRequest)定义事件处理程序。
确保已解决将ASP.NET应用程序升级到IIS 7.0的集成模式和经典模式之间的已知差异部分中讨论的任何问题:IIS 7.0集成模式和经典模式之间的差异。
实现IHttpModule接口的模块称为托管代码模块,因为它们是使用.NET Framework构建的。托管代码模块可以在服务器级别或应用程序级别注册。本机代码模块是仅在服务器级别注册的DLL(非托管代码)。核心ASP.NET功能(如会话状态和表单身份验证)在集成模式下实现为托管模块。
将应用程序从经典模式移动到集成模式时,可以为经典模式保留自定义模块和处理程序注册,也可以将其删除。如果不删除经典模式中使用的httpModules和httpHandlers注册,则必须将validation元素的validateIntegratedModeConfiguration属性设置为false以避免错误。 validation元素是system.webServer元素的子元素。有关详细信息,请参阅ASP.NET与IIS 7.0集成中的禁用迁移消息部分。