维护web.config文件

Question

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

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

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

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

您是否只是在服务器上手动更改web.config？

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

我很想知道其他人如何做到这一点。

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

我们正在寻求对此进行修订，因为我们想要一个可重现且不易遭受人为错误的程序。 我不认为解决方案是100％的web.config转换。 即使您使用转换，在部署中似乎仍然需要人工干预，因为生产配置文件中的值可能已更改，而在源代码管理中尚未更新。 其他人如何应对呢？

Answer 1

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

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

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

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

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

Answer 2

对我们来说，源代码管理是主存储。 凡是需要改变必须进入它。 试图通过修改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，然后上传整个版本。 然后可以在源代码管理中标记该版本。