场景如下：我在asp.net mvc 4项目上有多个开发人员。每个开发人员都有一个本地数据库。源代码控制系统是TFS，位于http://tfs.visualstudio.com。我们正在使用Azure网站托管该网站。我们还为连续部署配置了Azure网站。

源代码管理系统可以是git，mercurial，TFS等。老实说，我认为这并不重要。

我的问题是如何完成这三件事：

通过将各个连接字符串添加到machine.config中，我们实现了＃1的目标，从而使开发人员工作站设置之间没有冲突。

我最初是从web.config中删除connectionstrings部分的。在Azure网站(使用管理门户网站的Configure下)中，我配置了连接字符串，并且在观看Scott Hanselman的视频后，印象中它们将在部署时被动态地合并到我的web.config中，但这并没有似乎发生了。每当我进入打入数据库的任何页面时，都会收到一条错误消息，指出找不到连接字符串(或其他与连接相关的数据库错误)

如果将Azure连接字符串直接放在web.config中，那么事情就可以在Azure上运行，但是连接详细信息在每个人都可以看到的源代码控制中。

在阅读了Scott和David Ebbo的更多文章后，似乎我可以在web.config中放置一个空白连接字符串(使用正确的名称)，然后Azure将正确覆盖这些值。然后，我必须让开发人员将其连接字符串放在web.debug.config中，然后安装Slow Cheetah插件，以便他们可以F5并在本地进行测试。他们还不必将web.debug.config签入源代码管理中。 (使用TFS并不是那么容易)这似乎是一个沉重的负担，注定会失败。

我必须相信，这并不是一个罕见的问题。其他团队如何做到这一点？

环顾四周之后，如果没有对前/后构建过程进行大量命令行破解，实际上我所要求的内容实际上不受支持。我们最终要做的是强迫开发人员全部创建自己的本地数据库，使用受信任的身份验证，并建立供web.config中所有开发人员使用的SQL别名。这样，它就可以在每个人本地使用，它不会在源代码管理中公开任何用户名/密码，并且当从源代码管理中自动提取时，Azure仍然可以覆盖它。

慢猎豹实际上是一个不错的解决方案。它是web.config转换的扩展。这些转换使您可以保留一个web.config文件，然后为每个部署方案指定要对其进行哪些更改。例如，您的Release配置可能会删除debug属性。

这也可以用于更改连接字符串。在将项目部署到Azure的过程中将应用转换。

为了使它也可以与本地开发机器一起使用，我过去所做的就是将web.config与外部化的connections.config文件一起使用。每个开发人员都创建了一个connection.machinename.config文件，该文件在构建后的步骤中在构建时复制到connection.config。这些文件不必检入，并且它们决不会引起冲突，因为每个计算机名称都是唯一的。

release / staging / ..配置使用web.config转换将连接字符串元素替换为该部署的特定连接字符串(从而消除了对外部配置文件的依赖)。

Slow Cheetah提供了一些不错的助手，可以在设计时检查这些转换的结果。