asked on 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
C#
Last Comment
AndyAinscow
Your app doesn't know what the environment is automatically. You would need some way of telling it. I'd suggest three different files.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
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.
ASKER
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?
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
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.
ASKER
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.
ASKER
>>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-
If I understand correctly all three experts prefer having three separate files as suggested in the very first comment.