我很想知道其他人如何为已部署的应用程序维护他们的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转换 . 即使您使用转换，似乎部署中仍然需要一些人为干预，因为生成配置文件中的值可能已更改且尚未在源控件中更新 . 别人怎么解决这个问题？
2 回答
我们在VS 2010中使用web.config transformations .
您可以指定一个主要web.config文件，并使用转换来针对不同的环境（即更改数据库连接字符串）对其进行操作 . 部署/发布项目时会自动呈现这些转换 .
它还取决于需要部署的变更类型 . 虽然通常情况下，我们的部署设置仅替换已更新的文件 . 因此，如果我们改变的是web.config.production转换，那就是所有部署的 .
是的，我们确实将所有web.config文件及其转换保留在源代码管理下，因为它们是依赖它们的应用程序的一部分 .
我们还向其他团队/开发人员开放了某些环境，但不允许他们更改web.config设置，因此他们的部署/发布设置会跳过web.config文件 . 虽然作为一般规则， we don't touch files out on the server directly . 我们总是在本地更新文件，以便通过源代码控制跟踪更改并正确部署 .
我们的源代码控制是主店 . 任何需要改变的东西都要进入它 . 尝试通过修改PROD或STAGE站点上的配置设置来绕过此功能的开发人员会被破坏 . 如果出现问题，他们有责任解决任何问题 . 通常在第一次全明星之后，他们不再这样做了 . 然后使用xml / xslt将源控件配置文件内置到web.config和settings.config文件中
在我当前的项目中，我使用的web.config在所有环境中都是相同的，并使用configSource来引入特定于服务器的设置
每个环境都有自己的设置文件
appsettings.user1.dev.config
appsettings.user2.dev.config
appsettings.stage.config
appsettings.prod.config
我们的软件包发布脚本，抓取它需要的设置文件，并重命名为appsettings.config，然后上传整个版本 . 然后可以在源代码管理中标记该版本 .