因此在开发期间,一些开发人员可能会使用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转换.即使您使用转换,似乎部署中仍然需要一些人为干预,因为生成配置文件中的值可能已更改且尚未在源控件中更新.别人怎么解决这个问题？