因此在开发期间,一些开发人员可能会使用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转换.即使您使用转换,似乎部署中仍然需要一些人为干预,因为生成配置文件中的值可能已更改且尚未在源控件中更新.别人怎么解决这个问题？
解决方法
您可以指定一个主要web.config文件,并使用转换来针对不同的环境(即更改数据库连接字符串)对其进行操作.部署/发布项目时会自动呈现这些转换.
它还取决于需要部署的变更类型.虽然通常情况下,我们的部署设置仅替换已更新的文件.因此,如果我们改变的是web.config.production转换,那就是所有部署的.
是的,我们确实将所有web.config文件及其转换保留在源代码管理下,因为它们是依赖它们的应用程序的一部分.
我们还向其他团队/开发人员开放了某些环境,但不允许他们更改web.config设置,因此他们的部署/发布设置会跳过web.config文件.虽然作为一般规则,我们不直接在服务器上触摸文件.我们总是在本地更新文件,以便通过源代码控制跟踪更改并正确部署.
