• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 97
  • Last Modified:

How to read in application settings file in C# based on what environment the application is running from - Development, Test or Production

Hi Everyone,  

Our development team primarily develops Windows Form and Windows Service application using C# only.
We're trying to come up with a standard to use for all our applications when reading in settings from a settings file or app.config file.

The goal is to have our applications read in either Development, Test or Production settings based on what environment we deploy our application to.  How we determine the environment is based on what server the application is deployed to.  I'm just looking for some help from others on what's the most efficient way to do this and is there any industry standards we should use?  

For example, should we use just one app.config file with 3 different sets of variables in there or should we use 3 different settings files, one for DEV, TST and PRD?  When the application loads our goal is to read in the correct settings into our own class with properties that we can access throughout the application.

Any help would be greatly appreciated.  

Thank you so much.  
Scott Gabel
0
Scott Gabel
Asked:
Scott Gabel
  • 5
  • 4
  • 4
  • +1
3 Solutions
 
AndyAinscowFreelance programmer / ConsultantCommented:
Your app doesn't know what the environment is automatically.  You would need some way of telling it.  I'd suggest three different files.
0
 
it_saigeDeveloperCommented:
Or just the same setting name; e.g. - Environment with the various values; Development, Test and Production...

Another approach is if you know the server names and then you can resolve the server name using the HostName property in IPGlobalProperties; e.g. -
using System;
using System.Net.NetworkInformation;

namespace EE_Q29080752
{
    class Program
    {
        static void Main(string[] args)
        {
            var hostname = IPGlobalProperties.GetIPGlobalProperties().HostName;
            Console.WriteLine($"Host Name: {hostname}");
            Console.ReadLine();
        }
    }
}

Open in new window


Be aware that if the server name for an environment changes, then you will have to recompile...

-saige-
0
 
Éric MoreauSenior .Net ConsultantCommented:
I would use a single app.config file.

I would suffix each property in that file with a suffix representing the environment (ie. Prop1DEV, Prop1TST, Prop1PRD). But those won't be found automatically, you will need to append your suffix to your property name yourself.
0
Cloud Class® Course: Microsoft Exchange Server

The MCTS: Microsoft Exchange Server 2010 certification validates your skills in supporting the maintenance and administration of the Exchange servers in an enterprise environment. Learn everything you need to know with this course.

 
Éric MoreauSenior .Net ConsultantCommented:
Otherwise, you maintain 3 files (1 for each config) but you never copy them as part of your regular deployment. It will have to be a manual process.
0
 
Scott GabelAuthor Commented:
Thanks everyone for the comments.  I should have been more clearer in that our app does know what environment it is running from.  We're just looking for a clean way to set the single set of variables to use out of the 3 possible sets for DEV, TST and PRD.

Eric - your method is one method that we've used and it does work.  We were hoping go coming up with a solution where the correct set of variables would map on it's own based on environment.

Another thought we had is to use an INI file with 3 sections in it with sections headers [DEV], [TST} and [PRD].  We thought it might be easier to then pass the section header as a key in our code and the correct variables could be pulled over.
0
 
Éric MoreauSenior .Net ConsultantCommented:
>>I should have been more clearer in that our app does know what environment it is running from.  

You need to first find a method to detect your environment. It could be the name of the server, it could be an environment variable, ...

>>Eric - your method is one method that we've used and it does work.  

I have proposed 2. Which one have you tried?
0
 
AndyAinscowFreelance programmer / ConsultantCommented:
Just don't forget any method with one file requires extra code to determine which section (setting) to read and extra code to perform the read (and save?) when compared to three separate files.  (It also means any end user can have access to those settings you use internally in your organisation - possible security hole.)
0
 
Scott GabelAuthor Commented:
Thanks Eric - We have tried the 1st option you proposed.  We're using one app.config file.  But at the moment were prefixing out variables with the environment.  Ex DEVPath, TSTPath and PRD path.  I like your idea better with using the environment as a suffix, it makes the variable line up together.  The only thing we don't like is there is 3 blocks of IF checks in our code to set the default variables.  So if we have 20 variables to read in, the code gets lengthy, we were hoping for a cleaner way.

For example we have something like this:  (sorry I don't have the exact code in front of me so i'll just post pseudocode)

if (local == DEV)
{
   Path = DEVPath
}
else if (local == TST)
{
   Path = TSTPath
}
else if (local == PRD)
{
   Path = PRDPath
}

These if checks can get quite long when dealing with a hugh amount of variables to read in.
0
 
Scott GabelAuthor Commented:
Thank Andy,  I know what you mean with all the extra code to determine which section to read in when using one config file.  I never thought about the security holes, that's good to know.
0
 
Éric MoreauSenior .Net ConsultantCommented:
>>We're using one app.config file.  But at the moment were prefixing out variables with the environment.  Ex DEVPath, TSTPath and PRD path

If you wrap up your configuration settings in a class, you just have to write that code once and you simply forget it. Nobody would really care if you have long if or switch.

I personally use distinct configuration files. One for each environment. And when I deploy newer version, the configuration is never overwritten.
0
 
Scott GabelAuthor Commented:
>>If you wrap up your configuration settings in a class, you just have to write that code once and you simply forget it. Nobody would really care if you have long if or switch.

We're on the same page.  I've already started writing a class to wrap all this in.  We're trying to come up with a standard for all our apps, each app has different sets of variables so class properties would change for each app but the "If" logic would remain the same based on environment.

>>I personally use distinct configuration files. One for each environment. And when I deploy newer version, the configuration is never overwritten.

I also like the idea of 3 distinct configuration files.  Are you using 3 app.config files named separately for each environment or are you using 3 .settings files?  Do you deploy all 3 files to the location where the exe lives?  Or do you just deploy the correct file based on environment?
0
 
AndyAinscowFreelance programmer / ConsultantCommented:
Simplest is to have three different locations.  The app config file has the same name in each location with the same variables/sections.  No need for any unnecessary/duplicate code.
0
 
Éric MoreauSenior .Net ConsultantCommented:
>>I also like the idea of 3 distinct configuration files.  Are you using 3 app.config files named separately for each environment or are you using 3 .settings files?  Do you deploy all 3 files to the location where the exe lives?  Or do you just deploy the correct file based on environment?

I only have one app.config that I maintain in Visual Studio and it is for my DEV environment. I never deploy that file. I have created other files for other environments that I keep in the deployment folder. I never overwrite these other files.
0
 
it_saigeDeveloperCommented:
That is the way we do it Eric, each environment has it's own config...  We both manually and automatically deploy changes to the config files.

-saige-
0
 
AndyAinscowFreelance programmer / ConsultantCommented:
If I understand correctly all three experts prefer having three separate files as suggested in the very first comment.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

  • 5
  • 4
  • 4
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now