.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.
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.
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||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:
- If a change is made to the config (which should be rare), then all devs will be notified
- Regardless of technique (whether include or exclude), a localized copy should still be stored on each dev machine
- Each developer is ultimately responsible for updating their local copy.