处理多个发布目标时，如何处理不同实例的多个 web.config 转换？
我有一个 Asp.NET MVC 站点，我管理它的多个实例。每个实例都使用自己的数据库，但代码库都是相同的。为了促进这一点，我有几个具有匹配的 web.config 转换的构建配置，这样当我发布它时，它不会使用我的开发数据库，而是使用该站点实例的特定数据库。
今天当我去其中一个网站发布更新时出现了这个问题。我忘记更改构建配置，因此我发布到站点 A 时使用了适用于站点 B 的 web.config 转换，随之而来的是混乱和混乱。
有什么方法可以指定特定的发布目标仅与特定的构建配置一起使用？
或者有没有比杂乱构建配置更好的方法来处理这种情况？
I have an Asp.NET MVC site that I manage multiple instances of. Each instance uses it's own database but the code base is all the same. To facilitate this I have several build configurations with matching web.config transforms, so that when I publish it doesn't use my development database but instead uses the specific database for that site instance.
The problem with this came today when I went to publish an update to one of the sites. I forgot to change the build configuration, so my publish to site A was using a web.config transform that was meant for site B, and mayhem and confusion ensued.
Is there any way to to specify that a specific publish target will ONLY be used with a specific build configuration?
Or is there a better way to handle this situation than juggling build configurations?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
处理这类事情的一种方法，我不确定它是最好的，但它是一种方法，是在始终驻留在计算机上的更高级别的 web.config 或 machine.config 文件中设置某些配置值有问题。
然后确保您的项目文件不会覆盖这些配置值。
如果您这样做，这里有一些注意事项。
这样（这可能是优点也可能是缺点，具体取决于你的
环境）。
配置值，这可能会影响所有配置值，并且如果有多个
站点确实使用相同的配置值，在
来源将改变它们一切（同样，可能是赞成或反对
取决于）。
确定问题出在哪里或者是什么原因造成的。
或与您的托管提供商联系，具体取决于您的访问/安全性
权限，并且并不总是可以将 web.config 放在
比您的应用程序更高的级别。
显然，这里的好处是你可以在每台机器上配置不同的值，只要这些值没有在你的 web.config 中设置（这可能会导致错误），你就不必担心编译不同版本。
我相信 Visual Studio 2010 有一种方法可以为不同的构建类型设置不同的配置文件，但这听起来很像您已经在做的事情，因此忘记构建正确的方法仍然可能会得到类似的结果。
如果您可以使用 TFS Build 之类的东西，您可以尝试设置持续集成，在这种情况下，为产品构建的内容可以设置为始终以某种方式工作，并且始终从正确的构建类型中提取。
希望这里有帮助。
One way to deal with this sort of thing, and I'm not certain it's the best, but it is a way, is to set certain configuration values in a higher level web.config or machine.config file that always resides on the machine in question.
Then just make sure that your project files don't override those configuration values.
Here are some considerations if you do this.
this way (this could be a pro or a con depending on your
environment).
configuration values, this could affect them all, and if multiple
sites do use that same configuration value, changing it at the
source will change them all (again, could be a pro or a con
depending).
determine where the problem is or what is causing it.
or with your hosting provider depending on your access/security
privileges, and it's not always possible to put a web.config at a
higher level than your application.
Obviously the good thing here is that you can have a different value configured on each machine and as long as these values are not also set in your web.config (which would probably result in an error), you won't have to worry about compiling different versions.
I believe that Visual Studio 2010 has a way for setting different config files for different build types, but that sounds pretty much like what you are already doing, so forgetting to build the right way can still end up with similar results.
You could attempt to set up continuous integration with something like TFS Build if that is available to you, in which case what gets built for prod could be set up to always work a certain way and always pull from the correct build type.
Hope something here helps.
也许您可以采用一种解决方案，其中您不依赖于 Web 应用程序的“发布”对话框，该对话框要求您每次都进行正确的设置，而是使用类似自动命令行的解决方案（批处理文件、您自己的 msbuild目标，或像 CStroliaDavis 建议的构建服务器 [cruisecontrol、tfs、teamcity]）。
您只需从创建包的命令行调用“package”目标：
这还会创建一个 *.cmd 文件，以便您可以像这样部署它：
您可以将自定义 *.msbuild 文件添加到执行这些操作的解决方案中，或者也许最简单的方法是将命令添加到“工具”->“工具”中。外部工具。
Maybe you could go a solution where you don't rely on the 'Publish' dialog of the web application that requires you to make the right setting every time, but instead use a automated command-line like solution (batch file, your own msbuild target, or a build server like CStroliaDavis suggested [cruisecontrol, tfs, teamcity]).
You can just call the 'package' target from command line which creates a package:
This also creates a *.cmd file so you can deploy it like this:
You can add a custom *.msbuild file to your solution that performs these actions, or maybe it's easiest to just add a command to Tools -> External tools.
使用 kwateeSDCM，您不仅可以部署应用程序和 Web 应用程序，还可以管理实例参数或文件覆盖。我只在 tomcat wars 中使用过它，但它与语言或平台无关，因此我认为将其配置为与 ASP.NET 一起使用也应该很简单。
With kwateeSDCM you can not just deploy apps and web applications but you can also manage instance-by-instance parameters or file overrides. I've only used it with tomcat wars but it's not tied to a language or a platform so I suppose it should be straightforward to configure it to work with ASP.NET as well.