How do I handle multiple web.config transforms for different instances when dealing with multiple publish targets?

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.confi开发者_高级运维g 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?

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.

1. If you want to source control these values, it can be more difficult this way (this could be a pro or a con depending on your environment).
2. If other virtual sites are on the same machine and use the same 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).
3. If something is wrong with the value, it can be harder to determine where the problem is or what is causing it.
4. Getting to machine.config may be difficult in your organization 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.

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:

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

This also creates a *.cmd file so you can deploy it like this:

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

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.

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.