.net - 维护 web.config 文件

Question

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

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

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

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

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

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

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

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

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

Answer 1

我们使用 web.config transformations与 VS 2010。

您可以指定一个主要的 web.config 文件并使用转换来为不同的环境操作它(即更改数据库连接字符串)。当您部署/发布您的项目时，这些转换会自动呈现。

它还取决于需要部署什么类型的更改。尽管通常情况下，我们的部署设置是仅替换已更新的文件。因此，如果我们更改的只是 web.config.production 转换，那么部署的内容就是这些。

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

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