开发和生产之间的常见配置差异 (VB)

  • 项目

作者 ：Scott Mitchell

下载 PDF

在前面的教程中，我们通过将所有相关文件从开发环境复制到生产环境来部署网站。 但是，环境之间存在配置差异的情况并不少见，这就要求每个环境都有唯一 Web.config 文件。 本教程检查典型的配置差异，并探讨用于维护单独配置信息的策略。

简介

最后两个教程介绍了如何部署简单的 Web 应用程序。 使用 FTP 客户端部署站点教程介绍了如何使用独立的 FTP 客户端将所需的文件从开发环境复制到生产环境。 前面的教程 使用 Visual Studio 部署网站，介绍了如何使用 Visual Studio 的“复制网站”工具和“发布”选项进行部署。 在这两个教程中，生产环境中的每个文件都是开发环境中文件的副本。 但是，生产环境中的配置文件与开发环境中的配置文件不同并不少见。 Web 应用程序的配置存储在 Web.config 文件中，通常包括有关外部资源（如数据库、Web 和电子邮件服务器）的信息。 它还说明了应用程序在某些情况下的行为，例如发生未经处理的异常时要执行的操作过程。

部署 Web 应用程序时，正确的配置信息最终出现在生产环境中非常重要。 在大多数情况下， Web.config 开发环境中的文件无法按原样复制到生产环境。 相反，需要将 的 Web.config 自定义版本上传到生产环境。 本教程简要回顾一些更常见的配置差异;它还总结了用于维护环境之间不同配置信息的一些技术。

开发和生产环境之间的典型配置差异

该文件 Web.config 包含 ASP.NET 应用程序的各种配置信息。 无论环境如何，其中一些配置信息都是相同的。 例如，无论环境如何，文件的 <authentication> 和 元素中Web.config拼写的身份验证设置和 <authorization> URL 授权规则通常都是相同的。 但其他配置信息（例如有关外部资源的信息）通常因环境而异。

数据库连接字符串是配置信息的主要示例，这些信息因环境而异。 当 Web 应用程序与数据库服务器通信时，它必须首先建立连接，并通过连接字符串实现。 虽然可以直接在网页或连接到数据库的代码中对数据库连接字符串进行硬编码，但最好将其 Web.config<connectionStrings> 元素置于单个集中位置，以便连接字符串信息。 开发期间通常使用的数据库与生产中使用的数据库不同;因此，连接字符串信息对于每个环境必须是唯一的。

注意

以后的教程将探讨如何部署数据驱动应用程序，届时我们将深入了解数据库连接字符串在配置文件中的存储方式。

开发和生产环境的预期行为差异很大。 开发环境中的 Web 应用程序正在由一小组开发人员创建、测试和调试。 在生产环境中，许多不同的同时用户访问同一应用程序。 ASP.NET 包含许多功能，可帮助开发人员测试和调试应用程序，但在生产环境中，出于性能和安全原因，应禁用这些功能。 让我们看一些此类配置设置。

影响性能的配置设置

当第一次访问 ASP.NET 页 (或在) 更改后第一次访问该页面时，其声明性标记必须转换为类，并且必须编译此类。 如果 Web 应用程序使用自动编译，则页面的代码隐藏类也需要编译。 可以通过文件的 <compilation> 元素配置各种编译选项Web.config。

调试属性是 元素中 <compilation> 最重要的属性之一。 如果 属性 debug 设置为“true”，则编译的程序集包括调试符号，在 Visual Studio 中调试应用程序时需要这些符号。 但调试符号会增加程序集的大小，并在运行代码时施加额外的内存要求。 此外，当 属性设置为“true”时 debug ，不会缓存 返回 WebResource.axd 的任何内容，这意味着每次用户访问页面时，都需要重新下载 返回的 WebResource.axd静态内容。

注意

WebResource.axd 是 ASP.NET 2.0 中引入的内置 HTTP 处理程序，服务器控件使用该处理程序来检索嵌入的资源，例如脚本文件、图像、CSS 文件和其他内容。 有关工作原理 WebResource.axd 以及如何使用它从自定义服务器控件访问嵌入资源的详细信息，请参阅使用 WebResource.axd通过 URL 访问嵌入资源。

在 <compilation> 开发环境中，元素的 debug 属性通常设置为“true”。 事实上，此属性必须设置为“true”才能调试 Web 应用程序;如果尝试从 Visual Studio 调试 ASP.NET 应用程序，并且 属性 debug 设置为“false”，则 Visual Studio 将显示一条消息，说明在属性设置为“true”之前 debug 无法调试应用程序，并将为你提供此更改。

不应在生产环境中将 debug 属性设置为“true”，因为它会影响性能。 有关此主题的更全面讨论，请参阅 Scott Guthrie 的博客文章 不要在启用的情况下 debug="true" 运行生产 ASP.NET 应用程序。

自定义错误和跟踪

当 ASP.NET 应用程序中发生未经处理的异常时，它会冒泡到运行时，此时会发生以下三种情况之一：

  • 将显示一般运行时错误消息。 此页通知用户存在运行时错误，但不提供有关该错误的任何详细信息。
  • 将显示异常详细信息消息，其中包括刚刚引发的异常的相关信息。
  • 将显示一个自定义错误页，这是你创建的显示任何所需消息的 ASP.NET 页。

面对未经处理的异常时会发生什么情况取决于 Web.config 文件的 <customErrors> 部分。

开发和测试应用程序时，在浏览器中查看任何异常的详细信息会很有帮助。 但是，在生产环境中显示应用程序中的异常详细信息存在潜在的安全风险。 此外，它不讨人喜欢，使您的网站看起来不专业。 理想情况下，在发生未经处理的异常时，开发环境中的 Web 应用程序将显示异常的详细信息，而生产环境中的同一应用程序将显示自定义错误页。

注意

默认 <customErrors> 部分设置仅在通过 localhost 访问页面时显示异常详细信息消息，否则会显示泛型运行时错误页。 这并不理想，但可以肯定的是，默认行为不会向非本地访问者透露异常详细信息。 未来的教程将更详细地研究该 <customErrors> 部分，并演示如何在生产环境中发生错误时显示自定义错误页。

在开发过程中有用的另一个 ASP.NET 功能是跟踪。 跟踪（如果启用）会记录有关每个传入请求的信息， Trace.axd并提供一个特殊的网页 ，用于查看最近的请求详细信息。 可以通过 中的 Web.config元素打开和配置跟踪<trace>。

如果启用跟踪，请确保它在生产环境中处于禁用状态。 由于跟踪信息包括 Cookie、会话数据和其他潜在的敏感信息，因此在生产中禁用跟踪非常重要。 好消息是，默认情况下，跟踪处于禁用状态，并且 Trace.axd 只能通过 localhost 访问该文件。 如果在开发中更改这些默认设置，请确保在生产环境中将其关闭。

用于维护单独配置信息的技术

在开发和生产环境中使用不同的配置设置会使部署过程复杂化。 在前两个教程中，部署过程涉及将所有必要的文件从开发复制到生产环境，但仅当两个环境中的配置信息相同时，此方法才有效。 有多种技术可用于部署具有不同配置信息的应用程序。 让我们为托管的 Web 应用程序编录其中一些选项。

手动部署生产环境配置文件

最简单的方法是维护文件的两个版本 Web.config ：一个用于开发环境，一个用于生产环境。 将站点部署到生产环境需要将所有文件复制到开发环境中的生产服务器（文件除外Web.config）。 相反，特定于生产环境 Web.config 的文件将复制到生产环境。

此方法不是很复杂，但它很容易实现，因为配置信息很少更改。 它最适合具有小型开发团队的应用程序，这些团队托管在单个 Web 服务器上，并且其配置信息不经常更改。 使用独立 FTP 客户端手动部署应用程序文件时，这是最可行的。 使用 Visual Studio 的“复制网站”工具或“发布”选项时，需要先将特定于 Web.config 部署的文件与特定于生产的文件交换出来，然后再在部署完成后交换这些文件。

在生成或部署过程中更改配置

到目前为止，讨论假定了临时生成和部署过程。 许多大型软件项目都有更正式的流程，这些流程使用开源工具、本土工具或第三方工具。 对于此类项目，可以自定义生成或部署过程，以便在将配置信息推送到生产环境之前对其进行相应修改。 如果使用 MSBuild、 NAnt 或其他生成工具生成 Web 应用程序，则可能会添加生成步骤来修改 Web.config 文件以包含特定于生产的设置。 或者，部署工作流可以编程方式连接到源代码管理服务器并检索相应的 Web.config 文件。

为生产环境获取适当配置信息的实际方法因工具和工作流而异。 因此，我们不会进一步深入探讨本主题。 如果使用 MSBuild 或 NAnt 等常用生成工具，可以通过 Web 搜索找到特定于这些工具的部署文章和教程。

通过 Web 部署项目 Add-In 管理配置差异

2006 年，Microsoft 发布了 Visual Studio 2005 的 Web 开发项目 Add-In。 Visual Studio 2008 Add-In 于 2008 年发布。 此 Add-In 允许 ASP.NET 开发人员在其 Web 应用程序项目旁边创建单独的 Web 部署项目，生成后，该项目将显式编译 Web 应用程序，并将文件复制到本地输出目录。 Web 应用程序项目在后台使用 MSBuild。

默认情况下，开发环境 Web.config 的文件将复制到输出目录，但你可以设置 Web 部署项目来自定义

按以下方式复制到此目录的配置信息：

  • 通过 Web.config 文件节替换，在其中指定要替换的节和包含替换文本的 XML 文件。
  • 通过提供外部配置源文件的路径。 选中此选项后，Web 部署项目会将特定 Web.config 文件复制到输出目录 (，而不是 Web.config) 开发环境中使用的文件。
  • 通过将自定义规则添加到 Web 部署项目使用的 MSBuild 文件。

若要部署 Web 应用程序，请生成 Web 部署项目，然后将文件从项目的输出文件夹复制到生产环境。

若要了解有关使用 Web 部署项目的详细信息，检查 2007 年 4 月版 MSDN 杂志的此 Web 部署项目文章，或参阅本教程末尾的“进一步阅读”部分中的链接。

注意

不能将 Web 部署项目与 Visual Web Developer 一起使用，因为 Web 部署项目是作为 Visual Studio Add-In 实现的，Visual Studio Express版本 (包括 Visual Web 开发人员) 不支持加载项。

总结

开发中的 Web 应用程序的外部资源和行为通常与同一应用程序在生产环境中时不同。 例如，数据库连接字符串、编译选项以及发生未经处理的异常时的行为通常因环境而异。 部署过程必须适应这些差异。 如本教程中所述，最简单的方法是将备用配置文件手动复制到生产环境。 使用 Web 部署项目 Add-In 或更正式的生成或部署过程（可适应此类自定义项）时，可以实现更优雅的解决方案。

编程快乐！

深入阅读

有关本教程中讨论的主题的详细信息，请参阅以下资源：

上一页下一页