.NET Tip: Managing Development and Production Configuration Files

Wednesday Mar 21st 2007 by Eric Smith
Share:

If you use one server to develop your applications and another to deploy them, you probably have to change your database connection settings each time you deploy your configuration files. Learn a quick fix for this problem.

Most developers have one server they use to develop their applications and another server where they deploy the applications. The problem with this configuration is that you typically have to change your database connection settings, file locations, and so forth, each time you deploy your files. Inevitably, you'll add or remove settings from your configuration files and those settings won't be set up properly in the production environment.

A quick way to fix this problem is to use a prefix on your configuration settings and a function to determine which settings to use at runtime. Here's an example of a configuration file's appSettings section that is set up this way:

<appSettings>
   <add key="Location" value="dev"/>
   <add key="dev.ConnectionString"
        value="server=(localhost);database=mydb;
               uid=sa;pwd=sapassword"/>
   <add key="prod.ConnectionString"
        value="server=prodserver;database=mydb;
               uid=prodserver_user;pwd=produser_pwd"/>
</appSettings>

You then would create a function to wrap the ConfigurationManager class to determine which settings to retrieve, based on the Location setting:

private string GetSetting(string setting)
{
   string location = ConfigurationManager.AppSettings["Location"];
   return ConfigurationManager.AppSettings[location + "." + setting];
}

Using this function is pretty easy:

Response.Write(GetSetting("ConnectionString"));

When you deploy your code for this example, you can copy the entire configuration file to the server and simply change the Location from 'dev' to 'prod'. It's a fairly simple way to manage multiple configurations without a lot of work. You'd obviously want to beef up the GetSetting function to make sure that the setting wasn't empty, and so on, but the concept is something you might be able to use in your own applications.

About the Author

Eric Smith is the owner of Northstar Computer Systems, a Web-hosting company based in Indianapolis, Indiana. He is also a MCT and MCSD who has been developing with .NET since 2001. In addition, he has written or contributed to 12 books covering .NET, ASP, and Visual Basic. Send him your questions and feedback via e-mail at questions@techniquescentral.com.

Share:
Home
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved