.NET allows you to use .settings files to manage application settings. I would like to store Production, Development and Test settings separately in a way that I can do something like this:
EnvironmentSettings environmentSettings;
// get the current environment (Production, Development or Test)
ApplicationEnvironment Environment = (ApplicationEnvironment)
Enum.Parse(typeof(ApplicationEnvironment), Settings.Default.ApplicationEnvironment);
switch (Environment)
{
case ApplicationEnvironment.Production:
environmentSettings = Settings.Production;
break;
...
}
string reportOutputLocation = environmentSettings.ReportOutputLocation;
Basically, I want two separate Settings classes: the general Settings class that stores the selected environment and non-environment specific properties, and 3 static instances of a second class called EnvironmentSettings. The instance used should depend on the environment specified in the general Settings class.
Is there any way to do this short of manually setting the values for all these settings in a static constructor or something? If I have to do that, I'd rather just have one big Settings class with properties like "DevOutputLocation", "LiveOutputLocation", etc.
I can have multiple .settings files in my project but that just creates separate classes that don't derive from each other. So I could make DevelopmentSettings.settings, ProductionSettings.settings and TestSettings.settings files and give them the same properties, but then I would need a bunch of switch statements everywhere to determine which class to use because they don't derive from a common class.
One thought is that switching between a series of static values sounds like a rather fraught way of doing things. I would suggest looking up the Singleton pattern. This pattern gives you a single class instance that is shared between all references to the class, but when it's first loaded you can do your normal initialisation bits to check your environment and set the values accordingly.
Equally, rather than using switches to act on different classes, wouldn't you be looking at designing one Interface, and having each class implement that interface?
I am using this approach for .config files, I am sure that it will help you too. Just look on Scott Hanselman's blog post and this question. Ideology is simple like hell, but works pretty good. All you will need is:
Instantiation code for you class with settings will always look in default settings (which will be replaced after each build with the needed one), so this approach require minimal effort.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With