Managing web.config files

I have 3 environments: Dev, QA, Prod on .NET 4. Each of them has a unique web.config file. We had problems managing all three versions. It is easy to overlook something important when manually merging web.config files into TFS. More than once, we have completed the connection string pointing to QA on Prod.

So, I read about web.config conversions. They seem to require MSBUILD. We do not have a build server, so I'm not sure how I can try to use this solution. Is there a way to get conversions to work with regular web publishing?

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

+6
source share
4 answers

Is there a way to make conversions work with regular web publishing?

Absolutely, see this link on MSDN . You do not need MSBUILD. You can set connection strings for different environments in separate configuration files. For example, you might have Web.config, Web.QA.config, and Web.Prod.config, where QA and Prod are separate Visual Studio Build configurations .

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

Using this setting as an example, Web.config will have the entire configuration, Web.Debug.config will only have the configuration that changes for this environment (connection strings, application settings, etc.), and Web.Release.config has only the configuration that changes for this environment.

Once the settings and conversions are configured, you simply modify the assembly configuration, create and publish from Visual Studio.

+1
source

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

Yes, do not control them. The less we cope, the less chance of mistakes. They have exactly the same web.config files for all of your environments. The same distribution package is deployed everywhere.

And all environment-specific keys, such as base URLs, connection strings, ... can be defined in machine.config , which you deploy only once on each server and reuse from all of your applications. Or a web.config at the root of your IIS site from which all applications will be extracted.

+1
source

If you are using the websetup project to create msi, you can add your own installer class to websetup. This will give you the opportunity to create predefined command scripts that will correctly set values ​​in the web.config file

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

Here are some pages with an old example, enter the link here

+1
source

An alternative is to create a move of your settings, which change to an external file, and link this file using the configSource attribute. For partitions that are different, you put this in an external file.

Then you can either have separately named files, for example dev.config, qa.config, live.config, and change the name in the web.config file, or have 1 file called environment.config, and you never combine it between environments.

The disadvantage is that the entire settings section must be moved to a file.

Simon

0
source

Source: https://habr.com/ru/post/892324/


All Articles