.NET Tip: Managing Development and Production Configuration Files

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.



Comments

  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Live Event Date: May 6, 2014 @ 1:00 p.m. ET / 10:00 a.m. PT While you likely have very good reasons for remaining on WinXP after end of support -- an estimated 20-30% of worldwide devices still are -- the bottom line is your security risk is now significant. In the absence of security patches, attackers will certainly turn their attention to this new opportunity. Join Lumension Vice President Paul Zimski in this one-hour webcast to discuss risk and, more importantly, 5 pragmatic risk mitigation techniques …

  • With JRebel, developers get to see their code changes immediately, fine-tune their code with incremental changes, debug, explore and deploy their code with ease (both locally and remotely), and ultimately spend more time coding instead of waiting for the dreaded application redeploy to finish. Every time a developer tests a code change it takes minutes to build and deploy the application. JRebel keeps the app server running at all times, so testing is instantaneous and interactive.

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds