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.
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
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
Asked:
5
4-
4
- +1
3 Solutions
LVL 45
Your app doesn't know what the environment is automatically. You would need some way of telling it. I'd suggest three different files.
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. -
Be aware that if the server name for an environment changes, then you will have to recompile...
-saige-
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();
}
}
}
Be aware that if the server name for an environment changes, then you will have to recompile...
-saige-
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.
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.
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.
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.
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.
>>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?
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?
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.)
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.
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.
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.
>>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.
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.
>>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?
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?
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.
>>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.
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.
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-
-saige-
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 Already a member? Login.
Featured Post
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.
Tackle projects and never again get stuck behind a technical roadblock.
Join Now