维护 web.config 文件

Question

我很想知道其他人如何为已部署的应用程序维护 web.config 文件。 （假设没有自动部署机制——这超出了这个问题的范围）

因此，在开发过程中，一些开发人员可能会利用 web.config 转换，构建/发布他们的项目（调试/发布、测试/实时配置），然后将所有发布的工件部署到 Web 服务器并设置 IIS。一些开发人员可能会构建/发布他们的项目，将发布的工件部署到 Web 服务器，设置 IIS，然后为他们正在部署的特定环境（测试/实时等）手动更新 web.config。

一旦完成初始部署并且应用程序投入生产（在实时或测试环境中），如果数据库连接字符串或应用程序设置密钥需要更改，您将如何随着时间的推移维护 web.config 文件?

您是否使用 web.config 转换，在 VS 中进行更改重新发布应用程序，然后将整个应用程序或只是新的 web.config 复制到服务器？

您只是手动更改服务器上的 web.config 吗？

如果连接字符串、应用程序键等（而不是结构）发生变化，您是否对源代码管理中的 web.config 更改进行版本控制？

我很想知道其他人是如何解决这个问题的。

目前我们在生产中对 web.config 进行了更改。当我们实施新功能或错误修复时，我们会控制这些更改以及对 web.config 的任何更改，例如新的应用程序密钥等。如果我们必须部署应用程序的新版本，我们将在生产环境中备份当前版本服务器，删除所有文件异常配置文件，然后将没有配置文件的新版本复制到生产服务器，保留现有配置。然后手动将现有配置与我们在源代码控制中的配置进行比较，以说明架构的变化。

我们正在考虑修改它，因为我们想要一个可重现且不易受人为错误影响的程序。我不相信解决方案是 100% web.config 转换。即使您使用转换，部署中似乎仍然需要一些人工干预，因为生产配置文件中的值可能已更改并且尚未在源代码管理中更新。其他人是如何解决这个问题的？

Answer 1

我们在 VS 2010 中使用 web.config transformations。

您可以指定一个主要的 web.config 文件并使用转换来针对不同的环境对其进行操作（即更改数据库连接字符串）。这些转换会在您部署/发布项目时自动呈现。

这还取决于需要部署哪种类型的更改。虽然通常，我们的部署设置是仅替换已更新的文件。因此，如果我们只更改了 web.config.production 转换，那么这就是部署的全部内容。

是的，我们确实将所有 web.config 文件及其转换置于源代码控制之下，因为它们是依赖它们的应用程序的一部分。

我们还向其他团队/开发人员开放了某些环境，但不允许他们更改 web.config 设置，因此他们的部署/发布设置会跳过 web.config 文件。虽然作为一般规则，我们不会直接在服务器上修改文件。我们总是在本地更新文件，以便可以通过源代码管理跟踪更改并正确部署。

Answer 2

对我们来说，源代码控制是主存储。任何需要更改的内容 HAS 才能进入其中。试图通过修改 PROD 或 STAGE 站点上的配置设置来绕过此问题的开发人员会遭到破坏。如果出现问题，他们有责任解决任何问题。通常在第一个通宵之后，他们不再这样做了。然后使用 xml/xslt 将源代码控制配置文件构建到 web.config 和 settings.config 文件中

在我当前的项目中，我使用在所有环境中都相同的 web.config，并使用 configSource 来提取服务器特定设置

<appSettings configSource="App_Data\appsettings.config"/>

每个环境都有自己的设置文件

• appsettings.user1.dev.config
• appsettings.user2.dev.config
• appsettings.stage.config
• appsettings.prod.config

我们拥有的包发布脚本，抓取它需要的设置文件，并重命名为appsettings.config，然后整个发布被上传。然后可以在源代码管理中标记该版本。