The ConfigurationManager class introduced in .NET 2.0 makes it easy to read application settings from an XML file. I especially like the ability to derive a class from ConfigurationSection to hold custom settings for your application. This MSDN tutorial on creating custom configuration sections can help you get started.
I used this to make the configuration files for several of our Infovark add-ins, but ran into a snag with our main API library. In order to interoperate with COM, we had to put out Infovark.Api.dll in the GAC.
This presents a big problem for using *.config files. If your assembly is in the GAC, your configuration file must live in the GAC as well. (By default, configuration files are sidecar files located in the same directory as your *.exe file.) Since the GAC lives in a special place on a Windows machine, it’s difficult to read and write from that location without special permissions. And you can forget about browsing to it using Windows Explorer. This makes it tough for folks to change configuration options, which defeats the whole point of XML-based configuration files.
It’d be nice if we could load the configuration file from an specific spot on the computer. But while the Configuration object has both Save() and SaveAs() methods, there’s no corresponding Load() method. Huh? According to MSDN, the “right” way to point your application at a different configuration file is to create a whole new app domain with the appropriate settings. Um… sure.
How about we just hack up a workaround instead?
Using a dummy target
You can fool the configuration object into loading settings from whatever .config file you want, if you don’t mind a hack or two. The Configuration object exposes an OpenExeConfiguration() method that takes a string. Despite its name, you don’t have to pass it an .exe file. Any file path will do, as long as the path exists.
Since my .dll was in the GAC, I didn’t have a target for the OpenExeConfiguration() to use. I could have pointed it at another .dll — or at a .txt file for that matter — but that wouldn’t be very intuitive. Instead, I created a temporary file without an extension in the location I wanted to save the configuration file. Then I can open a Configuration object using the dummy target. Saving the Configuration object will cause it to write a file named “[configurationTarget].config” to the path I specified. You can see the code I used below.
///
-
/// Loads a .NET configuration file using the specified target.
-
/// Since configuration files are normally sidecar files, you
-
/// normally provide the path to an .exe or .dll file. Unlike
-
/// ConfigurationManager.OpenExeConfiguration(), this method
-
/// creates a dummy file without an extension to use as its target
-
/// if the target file does not always exist.
-
///
-
///
-
The path and name of the dummy file used as the target.
-
/// A Configuration object
-
public Configuration LoadConfiguration(string configurationTarget)
-
{
-
bool useDummyTarget=false;
-
try
-
{
-
FileInfo fi = new FileInfo(configurationTarget);
-
if (!fi.Exists)
-
{
-
useDummyTarget = true;
-
using (StreamWriter sw = fi.CreateText())
-
{
-
sw.WriteLine("Hi! This file only exists to make the Microsoft .NET framework happy.");
-
sw.WriteLine("It's important because Infovark can't load its configuration file without it.");
-
sw.WriteLine("(Don't ask. It's a long, long story.)");
-
sw.Flush();
-
sw.Close();
-
}
-
}
-
-
return ConfigurationManager.OpenExeConfiguration(configurationTarget);
-
}
-
catch(Exception e)
-
{
-
throw new ConfigurationErrorsException("Unable to load a configuration file using " + configurationTarget + " as a target. See inner exception for details.", e);
-
}
-
finally
-
{
-
// Clean up our dummy file.
-
if (useDummyTarget) File.Delete(configurationTarget);
-
}
-
}
Once I’ve opened the Configuration object, I don’t need the dummy file any more. I delete it to avoid have weird extension-less files hanging around.
It’s not pretty, but it gets the job done.
