6

I have 3 environments: Dev, QA, Prod on .NET 4. Each has a unique web.config file. We have been having problems managing all three versions. Its easy to overlook something critical when manually merging web.config files in TFS. More than once we have ended up with a connection string pointing to QA on Prod.

So, I read up on web.config transformations. These appear to require MSBUILD. We have no build server so I'm not sure how I can attempt to use this solution. Is there a way to make transformations work with a normal web publish?

Do you have any alternative suggestions for managing 3 web.config files?

P.Brian.Mackey
  • 43,228
  • 68
  • 238
  • 348

4 Answers4

1

Do you have any alternative suggestions for managing 3 web.config files?

Yes, don't manage them. The less we manage, the less chances of making mistakes. Have exactly the same web.config files for all your environments. Same distributive package deployed everywhere.

And all environment specific keys such as base urls, connection strings, ... could be defined in machine.config which you deploy only once on each server and reused from all your applications. Or a web.config at the root of your IIS site which all applications would derive from.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • 6
    I wouldn't like to see application settings being put in the machine.config. Quite often web servers host multiple applications & stuffing all the settings in the machine.config is a recipe for disaster. – Simon Halsey Jul 08 '11 at 13:43
1

Is there a way to make transformations work with a normal web publish?

Absolutely, take a look at this MSDN link. You do not need MSBUILD. You can set your connection strings for your various environments in separate config files. For example, you could have Web.config, Web.QA.config, and Web.Prod.config, where QA and Prod are separate Visual Studio Build configurations.

Alternatively, you could just use the build configurations that are added by default: Web.config (local development), Web.Debug.config (use for QA), and Web.Release.config (use for production).

Using this setup as an example, Web.config would have all configuration, Web.Debug.config would have only the config that changes for that environment (connection strings, app settings, etc), and Web.Release.config has only the config that changes for that environment.

Once your configs and transformations are setup, you just change your build configuration, build and publish from Visual Studio.

BrandonZeider
  • 8,014
  • 2
  • 23
  • 20
  • Do you then just "unbind" the web.debug.conf file from TFS so others can edit it? Ex: "File - Source Control - Exclude web.debug.config from source control." ? – Mark B Dec 20 '11 at 17:00
  • @MarkB, no need to unbind. it's a source file like any other. anyone should be able to edit it according to your TFS policy configuration. – Tsahi Asher Nov 12 '13 at 17:13
  • Is it possible to do this without using Publish? – Alex Jul 09 '14 at 11:53
1

If you use a websetup project to create an msi, you could add a custom installer class to websetup. This would give you the option of creating pre-defined batch scripts that would properly set the values in the web.config

msiexec.exe /Qb! /i "MyWebsiteMsi.MSI" SQL_SERVER_ConnStr="ABC"

Here's some page with an old example enter link description here

Lareau
  • 1,982
  • 1
  • 26
  • 47
0

An alternative is to create move your settings that change into an external file & link that file back in using the configSource attribute. For sections that differ you put that in an external file.

You can then either have separately named files, eg dev.config, qa.config, live.config & change the name in the web.config, or have 1 file say called environment.config & you never merge it between environments.

The downside is the whole setting section has to be moved into the file.

Simon

Simon Halsey
  • 5,459
  • 1
  • 21
  • 32