在处理多个发布目标时，如何处理不同实例的多个 web.config 转换？答案

【问题标题】：How do I handle multiple web.config transforms for different instances when dealing with multiple publish targets?在处理多个发布目标时，如何处理不同实例的多个 web.config 转换？
【发布时间】：2011-09-30 12:28:52
【问题描述】：

我有一个管理多个实例的 Asp.NET MVC 站点。每个实例都使用它自己的数据库，但代码库都是一样的。为了促进这一点，我有几个具有匹配 web.config 转换的构建配置，因此当我发布它时不使用我的开发数据库，而是使用该站点实例的特定数据库。

今天当我去发布其中一个网站的更新时，问题就出现了。我忘记更改构建配置了，所以我发布到站点 A 时使用了适用于站点 B 的 web.config 转换，随之而来的是混乱和混乱。

有什么方法可以指定特定的发布目标仅用于特定的构建配置？

或者有没有比杂耍构建配置更好的方法来处理这种情况？

【问题讨论】：

标签： visual-studio visual-studio-2010 deployment web-config

【解决方案1】：

处理这类事情的一种方法，我不确定它是否是最好的，但它是一种方法，是在始终驻留的更高级别的 web.config 或 machine.config 文件中设置某些配置值在有问题的机器上。

然后确保您的项目文件不会覆盖这些配置值。

如果您这样做，这里有一些注意事项。

如果您想对这些值进行源代码控制，可能会更加困难这种方式（这可能是赞成或反对，具体取决于您的环境）。
如果其他虚拟站点在同一台机器上并使用相同的配置值，这可能会影响它们全部，如果有多个站点确实使用相同的配置值，在来源将改变它们（再次，可能是赞成或反对取决于）。
如果值有问题，可能更难确定问题出在哪里或导致问题的原因。
在您的组织中访问 machine.config 可能很困难或与您的托管服务提供商合作，具体取决于您的访问/安全性权限，并且并不总是可以将 web.config 放在比您的应用程序更高级别。

显然这里的好处是你可以在每台机器上配置不同的值，只要这些值没有在你的 web.config 中设置（这可能会导致错误），你就不会担心编译不同的版本。

我相信 Visual Studio 2010 有一种方法可以为不同的构建类型设置不同的配置文件，但这听起来很像您已经在做的事情，所以忘记构建正确的方式仍然会导致类似的结果。

如果您可以使用 TFS Build 之类的东西，您可以尝试设置持续集成，在这种情况下，为 prod 构建的内容可以设置为始终以某种方式工作并始终从正确的构建类型中提取。

希望这里有所帮助。

【讨论】：

【解决方案2】：

也许您可以采用一种解决方案，不依赖于要求您每次都进行正确设置的 Web 应用程序的“发布”对话框，而是使用类似命令行的自动化解决方案（批处理文件，您自己的 msbuild 目标，或类似 CStroliaDavis 建议的构建服务器 [cruisecontrol, tfs, teamcity]）。

您可以从创建包的命令行调用“包”目标：

msbuild MyWebProject.csproj /t:Package /P:Configuration=Release;DeployIisAppPath="Default Web Site/Main/MyWebProject";PackageLocation="F:\MyWebProjectDeploy.zip"

这还会创建一个 *.cmd 文件，因此您可以像这样部署它：

F:\MyWebProjectDeploy.deploy.cmd /Y -allowUntrusted /M:http://webserver/MSDeployAgentService /U:Administrator /P:"Secret"

您可以将自定义 *.msbuild 文件添加到执行这些操作的解决方案中，或者将命令添加到工具 -> 外部工具可能是最简单的。

【讨论】：

虽然在赏金结束之前我没有时间测试这个，但我最喜欢你的想法。这似乎是最简单和最灵活的。

【解决方案3】：

使用kwateeSDCM，您不仅可以部署应用程序和 Web 应用程序，还可以逐个实例地管理参数或文件覆盖。我只将它与 tomcat wars 一起使用，但它与语言或平台无关，因此我认为将它配置为也可以与 ASP.NET 一起使用应该很简单。

【讨论】：