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