The World’s Leading Microsoft .NET Magazine
Sign-In | Register
   
 
timstall

Donate Today!

Search Box

 

Calendar

««Sep 2008»»
SMTWTFS
 
1
2
3
456
78910111213
14151617181920
21222324252627
282930

My RSS Feeds








Mailing List

Most Popular Tags

                                                           

Tips to Handle Config files for Testing and Deployment

« H E General .Net Techniques :: ASP.Net :: email
posted Monday, 28 February 2005

.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.

 ProCon
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 FileInclude/ExcludeWhyHow to get latestLocalize
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 VSSNeed 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.IncludeNeeded for NUnitAutomatic when getting project within VS.NetRun 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.

links: digg this    technorati    


comments (1)


1. anyoneis left...
Friday, 20 January 2006 2:36 pm :: http://davidrogers.blog-city.com/

For AppSettings, I like the "user.config" approach. This is enabled by adding a "file" attribute to the <appSettings> element in app.config or web.config, as in:

<appSettings file="user.config"> <add key="UpdateEnabled" value="true" /> <add key="ScramblePHI" value="true" /> </appSettings>

In app.config, I put the production settings, and so those end up in the project output directory and are easily incorporated in the deployed version.

Then, in the user.config file I put all of the development settings, as in:

<?xml version="1.0" encoding="utf-8" ?> <appSettings> <add key="UpdateEnabled" value="false" /> <add key="ScramblePHI" value="false" /> </appSettings>

Thus, the presence of the user.config file in my application directory gives me developer settings, which, if you don't make user.config part of the project, gives each developer their own persistent settings.

David