IIS7 应用程序池的 托管管道模式与集成模式小结

随着IIS 7全面融入.NET架构，其处理流程发生了深刻变革（如图所示）。这一变革的主要推动力源于ASP.NET角色的转变——从IIS的插件（ISAPI extension）进化为核心组件。在IIS 7中，ASP.NET不仅能处理多种请求类型，还能以模块的形式融入IIS的核心机制。

IIS 7的管道模式：经典与集成

IIS 7.0支持两种主要的管道模式：经典模式和集成模式。经典模式主要为了向后兼容，而集成模式则将ASP.NET与IIS紧密结合，提供更加一体化的解决方案。

应用程序池的设置允许管理员选择所需的管道模式，这使得一台服务器可以同时运行两种模式，为管理员提供了极大的灵活性。

经典模式

在IIS 6.0及之前的版本中，ASP.NET作为ISAPI扩展存在，而在IIS 7.0的经典模式中，这一角色得以保留。此模式下，IIS拥有自身的处理管道，这些管道可以通过ISAPI扩展进行扩展。ASP.NET作为其中一个ISAPI扩展运行。这意味着在经典模式中，ASP.NET的处理是相对独立的，与其他IIS模块存在一定的隔离。

在经典模式下，文件扩展名被用来决定使用哪个ISAPI处理程序。例如，.aspx和.ascx文件使用asp_isapi.dll处理，而传统的ASP页面使用asp.dll处理。这种模式在某些情况下非常有用，例如当Web Farm中同时包含IIS 6.0和IIS 7.0服务器时，或者当无法将web.config文件转换为新语法时。

集成模式

与经典模式不同，集成模式将ASP.NET融入IIS管道。在此模式下，原本属于ASP.NET的模块如FormsAuthentication、Session、Profile和RoleManager等现在成为IIS管道的有机部分。这意味着ASP.NET与IIS的界限被打破，两者更加紧密地结合在一起。

IIS管道提供了二十多种事件，这些事件可以被开发人员用来扩展Web服务器的功能。在集成模式下，ASP.NET可以利用这些事件，从而提供更加丰富的Web应用程序功能。这种模式为开发者提供了更大的灵活性，使他们能够更深入地利用IIS和ASP.NET的功能。

IIS 7通过整合.NET和引入两种管道模式，为Web开发者提供了更多的选择和更大的灵活性。无论是经典模式还是集成模式，都体现了IIS 7在保持传统兼容性的不断追求创新和进步的理念。通过定制模块和更新applicationHost.config文件，我们可以实现IIS 7.0中模块的自定义替换，而无需依赖微软公司提供的内置模块。这一变革为Web开发带来了更大的灵活性和自主性。

在两种模式之间的配置区别时，我们不难发现经典模式与集成模式在处理ASP.NET程序时的路径存在显著差异。经典模式需要将程序转入ASP.NET ISAPI过滤器，并在处理完毕后返回管道。而集成模式则将ASP.NET完全集成到IIS管道中，无论处理的是ASP.NET程序还是非ASP.NET程序，都在同一管道中进行，大大简化了处理流程。

随着IIS 7.0的推出，配置文件也得到了相应的更新。Web开发人员可以充分利用这些修改，其中节便是其中的一项重要改进。无论采用经典模式还是集成模式，都可以识别并应用此节。这一节既可以在applicationHost.config文件中进行设置，也可以在web.config文件中进行配置，能够同时对静态和动态页面进行控制。在经典模式下，节同样发挥着关键作用，帮助开发人员在web.config文件中设置不同的IIS配置。

在集成模式中，HTTP模块和HTTP处理程序不再定义于中，而是转移到了中。如果在集成模式下运行包含HTTP模块或HTTP处理程序的web.config文件，可能会出现失效的情况。幸运的是，微软公司已经提供了明确的错误信息提示（编号为500.22），指导开发人员进行web.config文件的迁移。

针对IIS 7.5中的节点配置问题，我们需要注意以下几点。在IIS7.5中，如果在集成模式下运行程序并尝试配置节点以自定义404页面，可能会发现这些配置不生效。这是因为程序运行在IIS7.0以后的集成模式下，需要在节点中进行相应的配置。为了程序在IIS7的集成模式下能完全生效，我们需要进行以下几个方面的修改：

（1）在节点中配置相当于中的的部分，用于定义自定义的HTTP模块。

（2）在节点中配置相当于中的的部分，用于定义自定义的HTTP处理程序。

（3）在下的节点配置相当于中的的部分，用于定义自定义的错误页面处理逻辑。

IIS7中ASP.NET的错误处理机制

在IIS7中，ASP.NET提供了多种错误处理机制，这些机制有助于开发人员更好地管理和应对应用程序中出现的错误。通过理解这些机制的不同配置和使用方式，我们可以更高效地处理用户遇到的错误，提供友好的出错信息，并优化应用程序的性能。

让我们看一下``配置。它允许我们自定义HTTP错误响应。通过移除`statusCode="404"`并添加新的错误路径和响应模式，我们可以实现自定义的404错误页面。其中，`errorMode`有三个可选值，分别决定了错误信息的显示方式。而`responseMode`则决定了如何响应错误请求。值得注意的是，``与``是不同的。前者主要处理HTTP相关的错误信息，后者则负责应用程序级的错误页面重定向。

接下来，我们来了解一下``配置和Application_Error事件。当应用程序级错误发生时，它们会优先执行Application_Error事件中的代码。如果该事件中调用了Server.ClearError()函数，则``配置节中的defaultRedirect不起作用。否则，错误页面会重定向到指定的URL页面，为用户显示友好的出错信息。这表明我们可以根据需要在不同错误处理机制之间进行选择。

从功能角度来看，Page_Error事件和Application_Error事件用于异常处理，而ErrorPage属性和``配置项则用于用户错误页面重定向。从错误处理的范围来看，Page_Error事件和ErrorPage属性用于页面级错误处理，而Application_Error事件和``配置项则用于应用程序级错误处理。

这些ASP.NET模块不仅适用于ASP.NET网页程序，还可以处理其他如ASP程序、PHP程序或静态HTML网页。由于ASP.NET的诸多功能已成为IIS7的一部分，这些类型的网页也可以利用ASP.NET的Forms认证、输出缓存等功能。IIS7允许开发人员使用ASP.NET API自行开发并加入模块，这使得ASP.NET网页开发人员更容易扩充IIS7和网站应用程序的功能。甚至，他们可以自行编写管理IIS7的程序，例如通过编程方式建立网站或虚拟目录。

在IIS7的执行架构方面，从IIS5到IIS6的改进主要集中在HTTP.sys上，而从IIS6到IIS7的改进则主要集中在ISAPI上。这些改进为开发人员提供了更强大的功能和更高效的性能。IIS7中的ASP.NET错误处理机制为开发人员提供了多种工具来有效地管理和应对应用程序中的错误，从而提供更好的用户体验和更可靠的应用程序性能。

通过深入理解这些错误处理机制并将其应用到实际开发中，我们可以更好地满足用户需求、提高应用程序的健壮性并提升整体的开发效率。无论是页面级还是应用程序级的错误处理，我们都可以根据具体情况选择最合适的错误处理机制来实现我们的目标。利用IIS7和ASP.NET的扩展功能，我们可以为网站应用程序带来更多的创新和可能性。