{
I'm having an evening when I can't believe what is wrong with me because something that should be trivial is giving me hell.
Our application has had connection strings littered all over the place - okay, 8 to be exact and I know this because of my frequent usage of "replace in files" to toggle connection strings. But we're at a point when this needs to be centralized and mutable without doing a new build.
In my head this is simple: slap a config file into the project and off I go. Some kind of one liner along the lines of:
ConfLib.CONNECTION = ConfigurationSettings.AppSettings["Connect"];
Simple, right? I do it with web applications all the time.
The first issue is that ConfigurationSettings, which the old school .NET folks are used to, is deprecated. The message tells you to use ConfigurationManager but neglects to mention that a physical reference to System.Configuration.dll (in the GAC) is needed. This isn't a big issue and 2 minutes later I've referenced it, and rewritten my line of code as:
ConfLib.CONNECTION = ConfigurationManager.AppSettings["Connect"];
Not quite. I'm now in the habit of doing unit tests so I realize that Visual Studio 2005 copies your libraries to a new directory when it does unit tests. I look at the "post build event" options and wonder if it's worth the hassle. So instead I ditch the unit test and return to the main solution, manually copy the *.config file into my application's directory and try.
No dice.
Maybe ConfigurationManager is too nebulous? So I try the following:
Configuration conf = ConfigurationManager.OpenExeConfiguration("ConfigHelper.dll");
Which, when I run it in the debugger seems to pull my keys out of the config file but gives me an access violation when I try:
ConfLib.CONNECTION = conf.AppSettings["Connect"];
This is quite some time later and I'm pretty annoyed because I must have absolutely not gotten the memo or configuration is bloated. Almost to prove to myself how simple this should be, I create a file called Settings.xml and put in a couple of elements and write the following:
XmlDocument configDoc = new XmlDocument();
configDoc.Load(Path.Combine(Directory.GetCurrentDirectory(), "Settings.xml"));
ConfLib.CONNECTION = configDoc.SelectSingleNode("//Database/text()").Value;
ConfLib.VERSION = configDoc.SelectSingleNode("//Version/text()").Value;
That simple.
Granted I am WELL AWARE that the Configuration API has lots of goodies stuffed into it but should that make the process of pulling it out of a configuration file so convoluted? Things that are designed well work for the simple things as easily as they solve the complex.
My configuration files always have the same pattern: I create a class that is designed to read the xml file with static variables for each configuration value. I use a static initializer to read these from the file and have a single static variable I reference when the app is loaded. I've worked on a lot of stuff that benefits from this but almost always configuration stuff seems to boil down to a simple name/value pair you can leverage.
I could have made an indexer and had the pulling look like the AppSettings collection on the ConfigurationManager but I dislike the fact that the compiler doesn't catch errors related to misspelled key names.
Oh well, I'll leave it in its current state. Maybe I'll get the memo tomorrow but I doubt it.
}
I'm having an evening when I can't believe what is wrong with me because something that should be trivial is giving me hell.
Our application has had connection strings littered all over the place - okay, 8 to be exact and I know this because of my frequent usage of "replace in files" to toggle connection strings. But we're at a point when this needs to be centralized and mutable without doing a new build.
In my head this is simple: slap a config file into the project and off I go. Some kind of one liner along the lines of:
ConfLib.CONNECTION = ConfigurationSettings.AppSettings["Connect"];
Simple, right? I do it with web applications all the time.
The first issue is that ConfigurationSettings, which the old school .NET folks are used to, is deprecated. The message tells you to use ConfigurationManager but neglects to mention that a physical reference to System.Configuration.dll (in the GAC) is needed. This isn't a big issue and 2 minutes later I've referenced it, and rewritten my line of code as:
ConfLib.CONNECTION = ConfigurationManager.AppSettings["Connect"];
Not quite. I'm now in the habit of doing unit tests so I realize that Visual Studio 2005 copies your libraries to a new directory when it does unit tests. I look at the "post build event" options and wonder if it's worth the hassle. So instead I ditch the unit test and return to the main solution, manually copy the *.config file into my application's directory and try.
No dice.
Maybe ConfigurationManager is too nebulous? So I try the following:
Configuration conf = ConfigurationManager.OpenExeConfiguration("ConfigHelper.dll");
Which, when I run it in the debugger seems to pull my keys out of the config file but gives me an access violation when I try:
ConfLib.CONNECTION = conf.AppSettings["Connect"];
This is quite some time later and I'm pretty annoyed because I must have absolutely not gotten the memo or configuration is bloated. Almost to prove to myself how simple this should be, I create a file called Settings.xml and put in a couple of elements and write the following:
XmlDocument configDoc = new XmlDocument();
configDoc.Load(Path.Combine(Directory.GetCurrentDirectory(), "Settings.xml"));
ConfLib.CONNECTION = configDoc.SelectSingleNode("//Database/text()").Value;
ConfLib.VERSION = configDoc.SelectSingleNode("//Version/text()").Value;
That simple.
Granted I am WELL AWARE that the Configuration API has lots of goodies stuffed into it but should that make the process of pulling it out of a configuration file so convoluted? Things that are designed well work for the simple things as easily as they solve the complex.
My configuration files always have the same pattern: I create a class that is designed to read the xml file with static variables for each configuration value. I use a static initializer to read these from the file and have a single static variable I reference when the app is loaded. I've worked on a lot of stuff that benefits from this but almost always configuration stuff seems to boil down to a simple name/value pair you can leverage.
I could have made an indexer and had the pulling look like the AppSettings collection on the ConfigurationManager but I dislike the fact that the compiler doesn't catch errors related to misspelled key names.
Oh well, I'll leave it in its current state. Maybe I'll get the memo tomorrow but I doubt it.
}