维护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

对我们来说，源代码控制是主存储。任何需要改变的事情都必须纳入其中。尝试通过修改 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
• 应用程序设置.stage.config
• 应用程序设置.prod.config

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