Tips to Handle Config files for Testing and Deployment

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/tips_to_handle_config_files_for_testing_and_deployment.htm]

.Net provides Config files to store configuration values for applications. Each application (an executable or web application) can have its own config file. Two common config files are:

• Web.Config - used by an ASP.Net or Web Service project.
• App.Config - used by executables like console apps or Windows Forms.

For example, a standard solution might include a web application (with a web.config) and a Console application to run unit tests (with a App.Config). There are challenges with config files for both testing and deployment:

• Testing - you may want to localize the config file to the test environment. For example, the app.config may store the database connection string, and you may want to set this connection string to the test database.
• Deployment - Each environment should have its own config. When you deploy an app to a new environment, you need to also have the correct config deployed too.

This prompts three questions:

• Should you include the config in the project file?
• How do you get the latest version of the config?
• How do you localize the config for a specific environment?

Let's look at each one of these:

Should you include the config in the project file?

Having a file in the physical directory, and having the file listed in the project are two different things. If in Visual Studio, Solution Explorer, you click "Show all files", you'll see all the files in the physical directory that aren't listed in the proj file.

	Pro	Con
Include	Easy to get the latest (just do a Get-Latest from VSS) Can be used by NUnit if you step through your tests in Visual Studio.	Hard for each developer to have their own individual copy.
Exclude	Easier for MSI Installer. If the config file isn't included, then deploying the MSI won't overwrite any existing config. This makes it very easy to redeploy the application without breaking the config. Each developer keeps local copy, doing a get-latest won't overwrite your localized copy because VS.Net's source control features only update files that are part of the project.	Config won't be available to NUnit or TestDriven.Net Plug-in (a free plug-in to let you run NUnit in Visual Studio).

How do you get the latest version of the config?

Two ways to get the latest version of a file:

• Pull from Visual Studio (such as doing a "Get-Latest")
• Push from VSS.

How do you localize the config for a specific environment?

Perhaps the best way to localize configs for your environment is to have a localized version in another folder, and then have a DOS script that can copy that localized version into the project folder.

Suggestion

Based on these questions, I've found the following parameters to work well.

Config File	Include/Exclude	Why	How to get latest	Localize
Web.Config - used for web application.	Exclude	Best for deployment. Re-running the MSI installer doesn't override the config (because it's not included in the MSI installer). Never run NUnit on Web app directly, so this isn't a problem.	Manually push from VSS	Need to localize it the first time, but then do nothing afterwards because a get-latest won't override it.
App.Config - used for Unit Tests.	Include	Needed for NUnit	Automatic when getting project within VS.Net	Run DOS script to copy in your localized files.

In terms of keeping configs updated, I find the following process helpful:

1. If a change is made to the config (which should be rare), then all devs will be notified
2. Regardless of technique (whether include or exclude), a localized copy should still be stored on each dev machine
3. Each developer is ultimately responsible for updating their local copy.